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Preface 


Objective 

The INCOSE Systems Engineering Handbook, version 3 (SEHv3), represents a shift in 
paradigm toward global industry application consistent with the Systems Engineering 
Vision. The objective for this document is to provide an updated description of the key 
process activities performed by systems engineers. The intended audience is the new 
Systems engineer, an engineer in another discipline who needs to perform systems 
engineering or an experienced systems engineer who needs a convenient reference. 

The descriptions in this handbook show what each systems engineering process 
activity entails, in the context of designing for affordability and performance. On 
some projects, a given activity may be performed very informally (e. g., on the back 
of an envelope, or in an engineer’s notebook); on other projects, very formally, with 
interim products under formal configuration control. This document is not intended 
to advocate any level of formality as necessary or appropriate in all situations. The 
appropriate degree of formality in the execution of any systems engineering process 
activity is determined by: 

a. the need for communication of what is being done (across members of a project 
team, across organizations, or over time to support future activities), 

b. the level of uncertainty, 

c. the degree of complexity, and 

d. the consequences to human welfare. 

On smaller projects, where the span of required Communications is small (few people 
and short project life cycle) and the cost of rework is low, systems engineering activities 
can be conducted very informally (and thus at low cost). On larger programs, where 
the cost of failure or rework is high, increased formality can significantly help in 
achieving program opportunities and in mitigating program risk. 

In a project environment, work necessary to accomplish project objectives is 
considered “in scope;” all other work is considered “out of scope.” On every project, 
“thinking” is always “in scope.” Thoughtful tailoring and intelligent application of 
the systems engineering process described in this handbook is essential to achieve the 
proper balance between the risk of missing project technical and business objectives 
on the one hand, and process paralysis on the other. Chapter 10 provides tailoring 
guidelines to help achieve that balance. 
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It is the intention of the SEHv3 steering committee that appendices will be developed 
to elaborate on significant topics, and that these appendices will be available on-line 
to members in the INCOSE Product Asset Library (IPAL). The addition of these 
on-line descriptions, work sheets, checklists, and how-to guides will evolve over 
time, and it is anticipated that all INCOSE members, working groups, and Corporate 
Advisory Board member companies will contribute to the creation of this resource. 
Actual content will be under the control of the IPAL working group. 

Approved: 

Terje Fossnes, Chair, INCOSE SEHv3 Development Team 
Kevin Forsberg, Co-Chair, INCOSE SEFIv3 Development Team 
Eric Aslaksen, INCOSE Associate Director, Technical Review 
Samantha Brown, INCOSE Technical Director 
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1 Systems Engineering Handbook Scope 

1.1 Purpose 

This handbook defines the discipline and practice of Systems engineering (SE) for 
student and practicing professional alike. This handbook provides an authoritative 
reference to understand the discipline in terms of content and practice. 

1.2 Application 

This handbook is consistent with ISO/IEC 15288: 2002(E) - Systems engineering- System 
life cycle processes (hereafter referred to as ISO/IEC 15288) to ensure its usefulness 
across a wide range of application domains - man-made Systems and products, as well as 
business and Services. 

ISO/IEC 15288 is an international Standard that is a generic process description, whereas 
this handbook further elaborates the processes and activities to execute the processes. 
Before applying this handbook in a given organization orproject, it is recommended that 
the tailoring guidelines in Chapter 10 be used to remove conflicts with existing policies, 
procedures and standards already in use. Processes and activities in this handbook do 
not supercede any international, national, or local laws or regulations. 

For organizations including much of commercial industry that does not follow the 
principles of ISO/IEC 15288 to specify their life-cycle processes, this handbook can 
serve as a reference to practices and methods which have proven beneficial to the 
Systems engineering community at large and which can add significant value in new 
domains if appropriately selected and applied. 

Material to support the application of processes and activities described in this 
handbook is available to INCOSE members through the INCOSE Process Asset 
Library (IPAL). The IPAL is currently under development and ultimately will contain 
additional supporting text, tailoring guidance and implementation material (such as 
checklists and work product templates from a number of application domains) for 
each handbook chapter. The handbook and IPAL are intended to be used together. 

1.3 Contents 

This chapter defines the purpose and scope of this handbook. Chapter 2 provides an 
overview of the goals and value of using systems engineering throughout the systems 
life cycle. Chapter 3 describes an informative life cycle model with six stages: 
Concept, Development, Production, Utilization, Support, and Retirement. 

ISO/IEC 15288 identifies four process groups to support systems engineering. Each 
of these process groups is the subject of a chapter. A graphical overview of these 
processes is given in Figure 1-1. 
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Figure 1-1 System Life Cycle Processes OverView per ISO/IEC 15288 

Technical Processes (Chapter 4) include stakeholder requirements definition, 
requirements analysis, architectural design, implementation, integration, 
verification, transition, validation, operation, maintenance, and disposal. 

ProjectProcesses (Chapter5) includeplanning, assessment, control, decision-making, 
risk management, configuration management, and information management. 

Enterprise Processes (Chapter 6) include enterprise management, investment 
management, system life cycle processes management, resource management, 
and quality management. As Figure 1-1 illustrates, the outputs of the system life 
cycle processes management process directs the tailoring of the Technical and 
Project processes. 

Agreement Processes (included in Chapter 6) address acquisition and supply. 

Activities that support these processes are further described in Chapters 7-9 - see 
Table 1-1 for an overview of topics. 

Enabling Systems Engineering Activities (Chapter 7) elaboratesonrequirements 
management, risk and opportunity management, and decision-making. 

System Life Cycle Processes Activities (Chapter 8) discusses selected topics 
within acquisition and supply, architectural design, configuration management, 
information management, investment management, project planning, quality 
management, resource management, validation, and verification. 

Specialty Engineering Activities (Chapter 9) contains practical information 
about topics such as acquisition logistics and human factors engineering. 
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Appendix A contains an n-squared analysis of the processes showing where 
dependencies exist in the form of shared inputs or outputs. Agreement processes 
are not included because their interaction with the other processes is most subject to 
enterprise tailoring. Other appendices included with this document provide a glossary 
of terms and acronyms. Errors, omissions and other suggestions for this handbook can 
be submitted to INCOSE using the User Feedback Form at the end of this document. 

Not every process will apply universally. Careful selection from the material 
that follows is recommended. Reliance on process over progress will not 
deliver a system. If you are not familiar with tailoring concepts, please read 
Chapter 10 before using this handbook 


Table 1-1 Systems Engineering Process Activities OverView 



Systems Engineering Process 
Activity 

Focus 

When it is most 
Useful 

7.0 

Enabling System Engineering 

- 

- 

7.1 

Decision Management 

Trade studies and project reviews 

Through Life 

7.2 

Requirements Management 

System requirements 

Through Life 

7.3 

Risk and Opportunity Management 

Recognizing opportunities and risks 

Through Life 

8.0 

Systems Engineering Support 

- 

- 

8.1 

Acquisition and Supply 

Procurement business relationships 

Through Life 

8.2 

Architectural Design 

Technical analysis 

Development Stage 

8.3 

Configuration Management 

Control of changes through life 

Through Life 

8.4 

Information Management 

Project archives and info exchange 

Through Life 

8.5 

Investment Management 

Estimation and analysis of costs 

Through Life 

8.6 

Project Planning 

Managing technical activities 

Through Life 

8.7 

Quality Management 

Product and process assessment 

Through Life 

8.8 

Resource Management 

Skills and resource availability 

Development Stage 

8.9 

Validation 

User concurrence - correct system 

Through Life 

8.10 

Verification 

Requirements met - system correct 

Through Life 

9.0 

Specialty Engineering Activities 

- 

- 

9.1 

Design for Acquisition Logistics 

Integrated logistics support Solutions 

Development Stage 

9.2 

Electromagnetic Compatibility 

Electro-magnetic protections 

Development Stage 

9.3 

Environmental Impacts 

Care for the biosphere and humans 

Development Stage 

9.4 

Human Factors 

Human capabilities and well-being 

Development Stage 

9.5 

Mass Properties 

Physical characteristics of the system 

Development Stage 

9.6 

Modeling, Simulation, & Prototype 

Early validation and testing 

Development Stage 

9.7 

Safety/Health Hazards 

Minimum risk to users 

Through Life 

9.8 

Sustainment Engineering 

Continued use of system 

Through Life 

9.9 

Training Need Analysis 

Basis for training requirements 

Development Stage 
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1.4 Format 

A common format has been applied in Chapters 4 through 6 to the elaboration of the 
system life cycle processes found in ISO/IEC 15288. Each process is illustrated by a 
context diagram. A sample is shown in Figure 1-2. To understand a given process, the 
reader is encouraged to find the complete information in the combination of diagrams 
and text. The following heading structure provides consistency in the discussion of 
these processes. 

• Purpose 

• Description 

• Inputs - this section discusses all inputs, including Controls and Enablers 

• Outputs 

• Process Activities 

• Common approaches and tips - endnotes contain additional readings 



Figure 1-2 Sample of Context Diagram for Process 


1.5 Definitions offrequently used terms 

This section contains the definition of some terms used frequently throughout this 
handbook. Definitions in italics have been taken from ISO/IEC 15288. A full glossary 
of definitions is found in Appendix B. 


Term 

Definition 

Activity 

set of actions that consume time and resources and whose performance is necessary 
to achieve or contribute to the realization of one or more outcomes 

Enabling system 

a system that complements a system-of-interest during its life cycle stages but does not 
necessarily contribute directly to its function during operation 

Enterprise 

that part of an organization with responsibility to acquire and to supply products 
and/or Services according to agreements 
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Term 

Definition 

Organization 

a group of people and facilities with an arrangement of responsibilities, authorities 
and relationships 

Process 

set of interrelated or interacting activities that transform inputs into outputs 

Project 

an endeavor with start and finish dates undertaken to create a product or Service in 
accordance with specified resources and requirements 

Stage 

a period within the life cycle of a system that relates to the State of the system 
description or the system itself 

System 

a combination of interacting elements organized to achieve one more stated purposes 

System elemen t 

a member of a set of elements that constitutes a system 

System-of-interest 

the system whose life cycle is under consideration 

Systems Engineering 

Systems Engineering is an interdisciplinary approach and means to enable the 
realization of successful systems. It focuses on defining customer needs and required 
functionality early in the development cycle, documenting requirements, and then 
proceeding with design synthesis and system validation while considering the 
complete problem. Systems Engineering considers both the business and the technical 
needs of all customers with the goal of providing a quality product that meets the user 
needs. (INCOSE) 


1.6 References 

The following documents have been used to establish the framework and practical 
foundations for this handbook. 

• INCOSE, Systems Engineering Handbook, version 2a, June, 2004. 

• ISO/IEC 15288: 2002(E), Systems engineering - System life cycle processes, 
Geneva: International Organization for Standardization, issued 1 November 
2002. 

• ISO/IEC TR 19760: 2003(E), Systems Engineering- A guide for the application 
of ISO/IEC 15288, Geneva: International Organization for Standardization, 
issued 15 November 2003. 
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2 Systems Engineering OverView 

2.1 Introduction 

This chapter offers a brief overview of the discipline of Systems Engineering, 
beginning with some definitions, an abbreviated survey of the origins of the discipline 
and discussions of the value of applying systems engineering. Systems are pervasive 
in our daily life. They are tangible in that they exist in the products we use, the 
technologies we employ, the Services we procure, and in the fabric of society. 

2.2 Definition of systems engineering 

Systems engineering is a profession, a process, and a perspective as illustrated by 
these three representative definitions. 

Systems engineering is a discipline that concentrates on the design and application 
of the whole (system) as distinct from the parts. It involves looking at a problem 
in its entirety, taking into account all the facets and all the variables and relating 
the social to the technical aspect. (Ramo ') 

Systems engineering is an iterative process of top-down synthesis, development, 
and operation of a real-world system that satisfies, in a near optimal manner, the 
full range of requirements for the system. (Eisner 2 ) 

Systems engineering is an interdisciplinary approach and means to enable the 
realization of successful systems. (INCOSE 3 ) 

Certain keywords emerge from this sampling - interdisciplinary, iterative, socio- 
technical, and wholeness. 

The systems engineering perspective is based on systems thinking. Systems’ thinking 
occurs through discovery, learning, diagnosis, and dialog that lead to sensing, 
modeling, and talking about the real-world to better understand, define, and work 
with systems. Systems thinking is a unique perspective on reality — a perspective that 
sharpens our awareness of wholes and how the parts within those wholes interrelate. 
A systems thinker knows how systems fit into the larger context of day-to-day life, 
how they behave, and how to manage them. Systems thinking recognizes circular 
causation, where a variable is both the cause and the effect of another and recognizes 
the primacy of interrelationships and non-linear and organic thinking — a way of 
thinking where the primacy of the whole is acknowledged. 

The systems engineering process has an iterative nature that supports learning and 
continuous improvement. As the processes unfold, systems engineers uncover the 
real requirements and the emergent properties of the system. Complexity can lead 
to unexpected and unpredictable behavior of systems, hence, one of the objectives 
is to minimize undesirable consequences. This can be accomplished through the 
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inclusion of and contributions from experts across relevant disciplines coordinated 
by the systems engineer. 

Since systems engineering has a horizontal orientation, the discipline (profession) 
includes both technical and management processes. Both processes depend upon 
good decision making. Decisions made early in the life cycle of a system, whose 
consequences are not clearly understood, can have enormous implications later in the 
life of a system. It is the task of the systems engineer to explore these issues and make 
the critical decisions in a timely manner. The role of the systems engineer is varied 
and Sheard 4 is one source for a description of these variations. 

2.3 Origins of systems engineering 

The modern origins of systems engineering canbe tracedto the 1930’s followed quickly 
by other programs and supporters. 5 Table 2-1 offers a thumbnail of some important 
highlights in the origins and history of the application of systems engineering. 

Table 2-1 Important Dates in the Origins of Systems Engineering as a Discipline 


1829 

Rocket locomotive; progenitor of main-line railway motive power 

1937 

British multi-disciplinary team to analyze the air defense system 

1939-1945 

Bell Labs supported NIKE development 

1951-1980 

SAGE Air Defense System defined and managed by MIT 

1956 

Invention of systems analysis by R AND Corporation 

1962 

Publication of A Methodology for Systems Engineering 

1969 

Jay Forrester (Modeling Urban Systems at MIT) 

1994 

Perry Memorandum urges military contractors to adopt commercial practices such as IEEE P 1220 

2002 

Release of ISO/IEC 15288 


With the introduction of the international Standard ISO/IEC 15288 in 2002, the 
discipline of systems engineering was formally recognized as a preferred mechanism 
to establish agreement for the creation of products and Services to be traded between 
two enterprises - the acquirer and supplier. But even this simple designation is often 
confused in a web of contractors and subcontractors as the context of most systems 
today is as a part of a “system of systems.” 

2.4 Systems o f systems 

“Systems-of-Systems” (SoS) are defined as an interoperating collection of component 
systems that produce results unachievable by the individual systems alone. 6 The 
systems considered in ISO/IEC 15288 

are man-made, created and utilized to provide Services in defined envi- 
ronments for the benefit of users and other stakeholders. These systems may 
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be configured with one or more of the following: Hardware, Software, humans, 
processes (e.g., review process), procedures (e. g., operator instructions), 
facilities, and naturally occurring entities (e.g., water, organisms, minerals). 

In practice, they are thought of as products or Services. The perception and 
definition of a particular system, its architecture and its System elements 
depend on an observer’s interests and responsibilities. One person’ s system- 
of-interest can be viewed as a system element in another person ’s system- 
of-interest. Conversely, it can be viewed as being part of the environment of 
operation for another person’ s system-of-interest . 7 

Figure 2-1 illustrates these concepts. The Global Positioning System (GPS), which is 
an integral part of the navigation system on board an aircraft, is a system in its own 
right rivaling the complexity of the air transportation system. Another characteristic 
of SoS is that the component systems may be part of other unrelated Systems. For 
instance, the GPS may be an integral part of automobile navigation systems. 

The following challenges all influence the development of systems of systems: 

1. System elements operate independently. Each system in a system of systems 
is likely to be operational in its own right. 

2. System elements have different life cycles. SoS involves more than one 
system element. Some of the system elements are possibly in their development 
life cycle while others are already deployed as operational. In extreme cases, 
older systems elements in SoS might be scheduled for disposal before newer 
system elements are deployed. 

3. The initial requirements are likely to be ambiguous. The requirements for 
a system of systems can be very explicit for deployed system elements. But for 
system elements that are still in the design stage, the requirements are usually 
no more explicit than the system element requirements. Requirements for SoS 
mature as the system elements mature. 

4. Complexity is a major issue. As system elements are added, the complexity 
of system interaction grows in a non-linear fashion. Furthermore, conflicting 
or missing interface standards can make it hard to define data exchanges across 
system element interfaces. 

5. Management can overshadow engineering. Since each system element 
has its own product/project office, the coordination of requirements, budget 
constraints, schedules, interfaces, and technology upgrades further complicate 
the development of SoS. 

6. Fuzzy boundaries cause confusion. Unless someone defines and Controls 
the scope of a SoS and manages the boundaries of system elements, no one 
Controls the definition of the external interfaces. 
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7. SoS engineering is never finished. Even after all system elements of a SoS are 
deployed, product/project management must continue to account for changes 
in the various system element life cycles, such as new technologies that impact 
one or more system elements, and normal system replacement due to pre- 
planned product improvement. 



Figure 2-1 Example of the multitude of perceivable systems-of-interest 
in an aircraft and its environment of operation within a 
Transport System-of-Systems 8 

A Camera as an Example of a System-of-Systems - Not all SoS involve an 
environment as complex as the air transportation system. A digital camera may 
seem simple, but it is a system of Systems with rigidly controlled interfaces. Multiple 
camera bodies, from simple fixed focus digital cameras to sophisticated single lens 
reflex cameras have a common interface to digital memory cards. The full single-lens 
reflex camera system has many different models of camera bodies which interface 
with 50 or more lens Systems and multiple flash units. To be a commercial success 
these simple to sophisticated camera systems are designed to conform to external 
interfaces for Standard commercial batteries, compact flash memory cards, interface 
cables, computers, and printer Software as illustrated in Figure 2-2. In the context of 
SoS, systems are enclosed in the white boxes, system elements are displayed in the 
gray area. 
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Figure 2-2 Digital Camera and Printer Systems of Systems 9 

Part of the Systems engineer’s job in the SoS environment is to be aware of and 
mitigate the risk of each of these seven challenges. Focus is placed on controlling the 
interfaces between system elements and external systems. It is especially important 
to ensure that the interfaces are still operational when an older component system is 
replaced with a newer version. Verification and validation processes play a critical 
role in such transitions. 


2.5 Use o f systems engineering 

As can be readily inferred from the nature of the earliest projects, the systems 
engineering discipline emerged as an effective way to manage complexity and 
change. Both complexity and change have escalated in our products, Services, and 
society. Reducing the risk associated with new systems or modifications to complex 
systems continues to be a primary goal of the systems engineer. This is illustrated 
in Figure 2-3. The percentages along the time line represent the actual life cycle cost 
(LCC) accrued over time - which means that the concept phase of a new system 
averages 8% of the total LCC. The curve for committed costs indicates the amount 
of LCC committed by the decisions taken. The curve indicates that when 20% of the 
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actual cost has been accrued, 80% of the total LCC has already been determined 
- based on a statistical analysis performed on projects in the US DoD as reported by 
the Defense Acquisition University. The light arrow under the curve reminds us that 
errors are less expensive to remove early in the lifecycle. 



Figure 2-3 Committed Life Cycle Cost against Time 10 

This figure also demonstrates the consequences of taking early decisions without 
the benefit of good information and analysis. Systems engineering extends the effort 
performed in concept exploration and design to exceed the percentages shown in 
the cumulative effort step-curve and reduce the risk of hasty commitments without 
adequate study. The recursive nature of modern development means that the execution 
of the various life cycle phases is not linear as illustrated - but the consequence of 
ill-formed decisions is the same. 

Another factor driving the need for systems engineering is that the time from 
prototype to significant market penetration of a new product has dropped by more 
than a factor of four in the past 50 years (Figure 2-4). Complexity has an impact on 
innovation. Few new products represent the big-bang introduction of new invention 
- most products and Services are the result of incremental improvement. This 
means that the life cycle of today’s products and Services is longer and subject to 
increasing uncertainty. A well-defined systems engineering process becomes critical 
to establishing and maintaining a competitive edge in the 21st century. 
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Figure 2-4 In the last century, the time from prototype to signiflcant market 
penetration is dramatically reduced 11 


2.6 Value o f systems engineering 

A study researching the return on investment from using systems engineering was 
conducted by the INCOSE Systems Engineering Center of Excellence beginning in 
2001 . The results uncovered an inverse correlation between cost and schedule overruns 
and the amount of systems engineering effort (SEE). As illustrated in the graph to the 
left in Figure 2-5, cost overrun lessens with increasing SEE and appears to minimize 
at something greater than 10% SEE. Variance in the cost overrun also lessens with 
increasing SEE. At low SEE, a project has difficulty predicting its overrun, which 
may be between 0% (actual = planned) and 200% (actual = 3 x planned). At 12% 
SEE, the project cost is more predictable, falling between minus 20% (actual = 0.80 x 
planned) and 41% (actual = 1.41 x planned). The dashed lines are the 90th percentile 
when assuming a normal distribution. 

Schedule overrun on the reported projects is illustrated in the right-hand graph in 
Figure 2-5. Two effects are apparent: 

• Schedule overrun lessens with increasing SEE. Overrun appears to minimize 
at something greater than 10% SEE, although few data points exist to support 
a reliable calculation. The solid line is the least-squares trend line for a second 
order curve. 
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• Variance in the schedule overrun also lessens with increasing SEE. At low 
SEE, a project has difficulty predicting its overrun, which may be between 
minus 35% (actual = 0.65 x planned) and 300% (actual = 4 x planned). At 12% 
SEE, the project cost is more predictable, falling between minus 22% (actual 
= 0.78 x planned) and 22% (actual = 1.22 x planned). The dashed lines are the 
90th percentile when assuming a normal distribution. 

Additional work is underway to collect more data about the value of applying systems 
engineering to a project. These initial results indicate that systems engineering effort 
can be a positive factor in controlling cost overruns and reducing the uncertainty of 
project execution. 



Figure 2-5 Cost and schedule overruns correlated 
with systems engineering effort 12 

An Allegorical Tale 

Upon casual reading, systems engineers appear to be responsible for everything that 
happens on a project and systems engineering appears to introduce excessive process 
overhead and non-value added activities. A senior systems engineer at a major US 
company visited all of the divisions with the goal of increasing the use of good system 
engineering practices. His message included all the things that SE can/should do in 
commercializing products. His message also included a strong bias towards planning 
and documentation. Over a period of months he visited with Division Managers, 
Chief Engineers, Program Managers and Senior Engineers. He returned completely 
depleted of his enthusiasm. The problem was that the message was totally rejected 
because it either looked like useless work or way beyond anything they could afford 
to do from a time and dollars perspective. Some time later another senior systems 
engineer visited many of the same people with the same purpose but a different 
message. The message this engineer delivered was that big gains could be made by 
focusing on the most important customer needs and using a select group of synergistic 
system engineering tools/practices. This time the message was well received. 
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The lesson: “Systems engineering is a multi-disciplinary effort that involves both the 
technical effort and technical project management aspects of a project. Enterprises 
seeking to incorporate the benefits ofprocesses outlined in ISO 15288 will remember 
that application of those processes, and the enablers discussed in this handbook, 
requires vision and practical application of the principles.” 13 
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13 Submitted by handbook review team 


Page 2.9 of 10 

Copyright ©2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. 


INCOSE-TP-2003-002-03 
June 2006 


INCOSE Systems Engineering Handbook v. 3 


THIS PAGE 
INTENTIONALLY 
LEFT BLANK 


Page 2.10 of 10 

Copyright ©2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. 


INCOSE-TP-2003-002-03 
June 2006 


INCOSE Systems Engineering Handbook v. 3 


3 Generic Life Cycle Stages 

3.1 Introduction 

Every man-made system has a life cycle, even if it is not formally defined. In keeping 
with increased awareness of environmental issues, the life cycle for any system-of- 
interest must encompass not only the development, production, and usage stages but 
also provide early focus on the retirement stage when decommissioning and disposal 
of the system will occur. 

The role of the systems engineer encompasses the entire life cycle for the system-of- 
interest. The systems engineer works closely with the project manager in tailoring 
the generic life cycle, including the decision gates, to meet the needs of their specific 
project. 

Per ISO/IEC 15288: “6.3 — The purpose and outcomes shall be defined for each 
stage of the life cycle. The life cycle processes and activities are selected, tailored 
as appropriate, and employed in a stage to fulfill the purpose and outcomes of that 
stage. ” 

The purpose in defining the system life cycle is to establish a framework for meeting 
the stakeholders’ needs in an orderly and efficient manner. This is usually done by 
defining life cycle stages, and using decision gates to determine readiness to move 
from one stage to the next. Skipping phases and eliminating “time consuming” 
decision gates can greatly increase the risks (cost and schedule), and may adversely 
affect the technical development as well by reducing the level of systems engineering 
effort as discussed in Section 2.6. 

Systems engineers orchestrate the development of a solution from requirements 
determination through operations and system retirement by assuring that domain 
experts are properly involved, that all advantageous opportunities are pursued, and 
that all significant risks are identified and mitigated. 

Systems engineering tasks are usually concentrated at the beginning of the life cycle, 
but both commercial and government organizations recognize the need for systems 
engineering throughout the systems life span, often to modify or change a system 
product or Service after it enters production or is placed in operation. 

3.2 Life Cycle Characteristics 

3.2.1 Three Aspects of the Life Cycle 

Every system or product life cycle consists of the business aspect (business case), the 
budget aspect (funding), and the technical aspect (product). The systems engineer 
creates technical Solutions that are consistent with the business case and the funding 
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constraints. System integrity requires that these three aspects are in balance and 
given equal emphasis at all decision gate reviews. For example, when the Iridium 
project started in the late 1980s the concept of satellite-based mobile phones was a 
breakthrough, and would clearly capture a significant market share. Over the next 
dozen years, the technical reviews ensured a highly successful technical solution. In 
fact, in the first decade of the 21st century, the Iridium project is proving to be a good 
business venture for all except for the original team who had to sell all the assets — at 
about two percent of their investment — through the bankruptcy court. The original 
team lost sight of the competition and changing consumer patterns that substantially 
altered the original business case. Figure 3-1 highlights two critical parameters that 
engineers sometimes lose sight of: time to break even (indicated by red circle) and 
Return on Investment (ROI; indicated by green line (lower curve)). 


Business Development, Marketg 


System Engineering 



Figure 3-1 Generic Business Life Cycle 1 

3.2.2 Decision Gates 

Decision gates, also known as control gates, are often called “Milestones” or 
“Reviews.” All decision gates are both reviews and milestones; however, not all 
reviews and milestones are decision gates. Decision gates address the following 
questions: 

• Does the project deliverable still satisfy the business case? 

• Is it affordable? 

• Can it be delivered when needed? 

Decision gates represent major decision points in the system life cycle. They ensure 
that new activities are not pursued until the previously scheduled activities, on which 
new ones depend, are satisfactorily completed and placed under configuration control. 
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The primary objectives of decision gates are to: 

• Ensure that the elaboration of the business and technical baselines are acceptable 
and will lead to satisfactory verification and validation. 

• Ensure that the risk of proceeding to the next step is acceptable. 

• Continue to foster buyer and seiler teamwork. 

Decision gate approval follows review by qualified experts and involved stakeholders 
and is based on hard evidence of compliance to the criteria of the review. Detailed 
information about the decision gate activity is provided in chapter 7.1. 

There are at least two decision gates in any project: authority to proceed and final 
acceptance of the project deliverable. The project team needs to decide which life 
cycle stages are appropriate for their project and which decision gates beyond the 
basic two are needed. Each decision must have a beneficial purpose; “pro-forma” 
reviews waste everyone’s time. Even in agile development frequent interaction with 
the customer may minimize, but not eliminate, the need for decision gates. The 
consequences of conducting a superficial review, omitting a critical discipline, or 
skipping a decision gate altogether are usually long-term and costly. 

3.3 Life Cycle Stages 

ISO/IEC 15288 States: “6.2 - A life cycle model that is composed of stages shall he 
estahlished. The life cycle model comprises one or more stage models, as needed. It 
is assembled as a sequence of stages that may overlap and/or iterate, as appropriate 
for the scope, magnitude, and complexity, changing needs and opportunities.’’ 

Table 3-1 lists the six life cycle stages that are identified in ISO/IEC 15288. The 
purpose of each is briefly identified in the table, and the options from decision gates 
events are indicated. Note that stages can overlap, and the utilization and support 
stages run in parallel. Note also that the outcome possibilities for decision gates are 
the same for all decision gates, from the first in the concept review to the last one in 
the retirement stage. Subsequent chapters of this handbook will define processes and 
activities to meet the objectives of these lifecycle stages. 
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Table 3-1 Life cycle stages, their purposes, and decision gate options 2 


LIFE CYCLE 
STAGES 

PURPOSE 

DECISION GATES 

CONCEPT 

Identify stakeholders’ needs 
Explore concepts 
Propose viable Solutions 

Decision Options 

- Execute next stage 

- Continue this stage 

- Goto a preceding stage 

- Hold project activity 

- Terminate project 

DEVELOPMENT 

Refine system requirements 
Create solution description 
Build system 

Verify and validate system 

PRODUCTION 

Produce Systems 
Inspect and test [verify] 

UTILIZATION 

Operate system to satisfy users’ needs 

SUPPORT 

Provide sustained system capability 

RETIREMENT 

Store, archive, or dispose of the system 


Figure 3-2 compares the life cycle stages of the ISO/IEC 15288 to other life cycle 
viewpoints. For example, the Concept Stage is aligned with the commercial project’s 
Study Period; and with the Pre-systems Acquisition and the Project Planning Period 
in the US Departments of Defense and Energy, respectively. Typical decision gates 
are presented in the bottom line. Various life cycle models such as the waterfall, 
spiral, Vee, and agile development models are useful in defining the start, stop, and 
activities appropriate to life cycle stages. 

The Vee model is used to visualize the system engineering focus, particularly during 
the concept and development stages. The Vee highlights the need to define verification 
plans during requirements development, the need for continuous validation with the 
stakeholders, and the importance of continuous risk and opportunity assessment. 
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Figure 3-2 Comparison of life cycles 3 

The Vee model provides a useful illustration of the Systems engineering activities 
diiring the life cycle stages. In the Vee model, time and system maturity proceed from 
left to right. The core of the Vee depicts the evolving baseline from user requirements 
agreement to Identification of a system concept to definition of Systems components 
that will comprise the final product. With time moving to the right and with the 
system maturity shown vertically, the evolving baseline defines the left side of the 
core of the Vee, as shown in figure 3-3. As entities are constructed, verified and 
integrated, the right side of the core of the Vee is executed. 
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(In-process validation) 

“Are the proposed baselines acceptable?" 



Off-Core opportunity & risk management 
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"How are the opportunities and risks of the 
proposed baselines being resolved?" 


Figure 3-3 Left side of the Vee model 4 

Since one can never go backward in time, all iterations in the Vee are performed on 
the vertical “time now” line. Upward iterations involve the stakeholders and are the 
in-process validation activities that assure that the proposed baselines are acceptable. 
The downward vertical iterations are the essential off-core opportunity and risk 
management investigations and actions. 

In each stage of the system life cycle the systems engineering process iterates to 
ensure that a concept or design is feasible, and that the stakeholders remain supportive 
of the solution as it evolves. In the following paragraphs, the text in italics has been 
taken from ISO/IEC 15288, Appendix B, where detailed activities and outcomes for 
each life cycle stage are itemized. 

3.3.1 Pre-Concept Exploratory Research Stage 

The Pre-Concept Exploratory Research Stage is sometimes referred to as the User 
Requirements Definition Phase. In many industries, it is common for research studies 
to lead to new ideas or enabling capabilities which then mature into the initiation of a 
new project (system-of-interest). A great deal of Creative systems engineering is done 
in this exploratory stage, and the systems engineer leading these studies is likely to 
follow a new idea into the Concept Stage, perhaps as project Champion. Often the Pre- 
Concept activities identify the enabling technologies. As discussed in chapter 2, if the 
work is done properly in early stages of the life cycle, it is possible to avoid recalls, 
and rework in later stages. 
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3.3.2 Concept Stage 

Purpose: The Concept Stage is executed to assess new business opportunities and to 
develop preliminary system requirements and a feasible design solution. 

This stage is a refinement and broadening of the studies, experiments, and engineering 
models pursued during the Pre-Concept Stage. The processes described in this 
handbook are requirements-driven, as opposed to product driven. Thus, the first step 
is to identify, clarify, and document stakeholders’ requirements. If there was no Pre- 
Concept stage, that effort is done here. 

During the Concept Stage, the team begins in-depth studies that evaluate multiple 
candidate concepts and eventually provide a substantiated justification for the system 
concept that is selected. As part of this evaluation mockups may be built (for hardware) 
or coded (for Software), engineering models and simulations may be executed, and 
prototypes of critical components may be built and tested. Prototypes are helpful to verify 
the feasibility of concepts and to explore risks and opportunities. These studies expand 
the risk and opportunity evaluation to include affordability assessment, environmental 
impact, failure modes, and hazard analysis. Key objectives are to provide confidence 
that the business case is sound and the proposed Solutions are achievable. The Systems 
engineer coordinates the activities of engineers from many disciplines. 

Early validation efforts align requirements with stakeholder expectations. The Systems 
capabilities specified by the stakeholders will be met by the combination of system 
elements. Problems identified for individual hardware parts or Software modules 
should be addressed early to minimize the risk that, when these entities are finally 
designed and verified, they fail short of the required functionality or performance. 

Many projects are driven by eager project champions who want “to get on with it.” They 
succumb to the temptation to cut short the concept stage, and they use exaggerated 
projections to support starting detailed design without adequate understanding of 
the challenges involved. Many commissions reviewing failed Systems after the fact 
have identified insufficient or superficial study in the concept stage as a root cause 
of failure. 

3.3.3 Development Stage 

Purpose: The Development Stage is executed to develop a system-of-interest that 
meets acquirer requirements and can be produced, tested [verified], evaluated, 
operated, supported, and retired. 

The development stage includes development, and integration, verification and 
validation (IV&V) activities. Figure 3-4 illustrates the evolving baseline as system 
components are integrated and verified. A source of additional information about 
IV&V and the significance for project cost and risk when these activities are optimized 
was the subject of the European Union SysTest 5 program. 
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Off-core User Approval 
of Baseline and Baseline Modification 
“Is the verified performance acceptable?" 



“Off-Core” Verification Problem 


Investigation and Resolution 
"is the problem cause understood?" 


Figure 3-4 Right side of the Vee 6 

3.3.4 Production Stage 

Purpose: The Production Stage is executed to produce or manufacture the product, 
to test [verify] the product, and to produce related supporting and enabling Systems 
as needed. 

Product modifications may be required to resolve production problems, to reduce 
production costs, or to enhance product or system-of-interest capabilities. Any of 
these may influence system requirements, and may require system re -verification 
or re-validation. All such changes require Systems engineering assessment before 
changes are approved. 

3.3.5 Utilization Stage 

Purpose: The Utilization Stage is executed to operate the product, to deliver Services 
within intended environments and to ensure continued operational effectiveness. 

Product modifications are often planned for introduction throughout the life cycle. 
Such upgrades enhance the capabilities of the system. These changes should be 
assessed by systems engineers to ensure smooth integration with the operational 
system-of-interest. The corresponding technical process is the Operations Process. 

3.3.6 Support Stage 

Purpose: The Support Stage is executed to provide logistics, maintenance, and 
support Services that enable continued system-of-interest operation and a sustainable 
Service. 
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Modifications may be proposed to resolve supportability problems, to reduce 
operational costs, or to extend the life of a system. These changes require systems 
engineering assessment to avoid loss of system capabilities while under operation. 
The corresponding technical process is the Maintenance Process. 

3.3.7 Retirement Stage 

Purpose: The Retirement Stage is executed to provide for the removal of a system- 
of-interest and related operational and support Services, and to operate and support 
the retirement system itself. 

Systems engineering activities in this stage are primarily focused on ensuring that 
disposal requirements are satisfied. In fact, planning for disposal is part of the system 
definition during the concept stage. Experience in the 20th century repeatedly 
demonstrated the consequences when system retirement and disposal are not 
considered from the outset. Early in the 21st century, many countries have changed 
their laws to hold the creator of a system-of-interest accountable for proper end-of- 
life disposal of the system. 

3.4 Development Stage Approaches 

Per ISO/IEC 15288: “6.3 - Different organizations may undertake different stages in 
the life cycle. However, each stage is conducted by the organization responsible for 
that stage with due consideration of the available information on life cycle plans and 
decisions made in preceding stages. Similarly, the organization responsible for that 
stage records the decisions made and records the assumptions regarding subsequent 
stages in the life cycle. ” 

A discussion of System Life Cycle Stages does not imply that the project should follow 
a predetermined set of activities or processes unless they add value toward achieving 
the final goal. Representations of stages tend to be linear in graphical depictions, 
but this hides the true incremental and iterative nature of the underlying processes. 
Illustrations which follow imply full freedom to choose a development model and are 
not restricted to a waterfall or other plan-driven methods. For the development stage, 
as for all stages, the organization will select the processes and activities that suit the 
project needs. 

3.4.1 Plan-driven Development 

The requirements/design/build/test/deploy paradigm is considered the traditional 
way to build systems. On projects where it is necessary to coordinate large teams of 
people working in multiple companies, plan-driven approaches provide an underlying 
framework to provide discipline to the development processes. Plan-driven methods 
are characterized by a systematic approach that adheres to specified processes as 
the system moves through a series of representations from requirements through 
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design to finished product. There is attention to the completeness of documentation, 
traceability from requirements, and verification of each representation after the fact. 

The strengths of plan-driven methods are predictability, stability, repeatability, 
and high assurance. Process improvement focuses on increasing process capability 
through standardization, measurement, and control. These methods rely on the 
“master plans” to anchor their processes and provide project-wide communication. 
Historical data is usually carefully collected and maintained as inputs to future 
planning to make projections more accurate. 7 

Safety-critical products, such as the Therac-25 medical equipment described in 
section 3.5.1, can only meet modern certification standards by following a thorough, 
documented set of plans and specification. Such standards mandate strict adherence 
to process and specified documentation to achieve safety or security. However, 
unprecedented projects or projects with a high rate of unforeseeable change, 
predictability and stability degrade, and a project may incur significant investment 
trying to keep documentation and plans up-to-date. 

3.4.2 Incremental and Iterative Development 

Incremental and iterative development (IID) methods have been in use since the 
1960’s. 8 They represent a practical and useful approach which allows a project to 
provide an initial capability followed by successive deliveries to reach the desired 
system-of-interest. The goal is to provide rapid value and responsiveness. This 
approach is generally presented in opposition to the perceived burden associated with 
using any process, including those defined in this handbook. 

This development approach is used when the requirements are unclear from 
the beginning or the customer wishes to hold the system-of-interest open to the 
possibilities of inserting new technology. Based on an initial set of assumptions a 
candidate system-of-interest is developed, and then assessed to determine if it meets 
user needs or requirements. If not, another evolutionary round is initiated. This 
process is repeated until there is a satisfied user, or until the investor runs out of 
interest or money. 

Most literature agrees that IID methods are best applied to smaller, less complex 
systems or to system elements. The focus is on flexibility, and allowing selected 
events to be taken out of sequence when the risk is acceptable. Tailoring in this way 
highlights the core activities of product development. 

The features that distinguish IID from the plan-driven approaches are velocity and 
adaptability. While market strategies often emphasize that “time to market” or speed 
is critical, a more appropriate criterion is “velocity,” which considers direction in 
addition to speed. By incorporating the customer into their working-level teams, the 
project receives continuous feedback that they are going in a direction that satisfies 
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the customer’s highest needs first. One downside is that reactive project management 
with a customer that often changes direction can result in an unstable, chaotic 
project. On one hand, this approach avoids the loss of large investments in faulty 
assumptions; on the other hand, emphasis on a tactical viewpoint may generate short- 
term or localized solution optimizations. 

A specific IID methodology called evolutionary development 9 is common in research 
and development environments. Figure 3-5 illustrates how this approach was used in 
the evolution of the tiles for the NASA Space Shuttle. 10 



Figure 3-5 IID and Evolutionary Development 11 
3.4.3 What is best for your organization? 

Conway’s law suggests that effective systems design emerges from system-oriented 
organizations. One of the earliest books on Systems Engineering Management 12 
identified three simple criteria for such an organization; facilitate Communications, 
streamline Controls, and simplify paperwork. The way to effective systems engineering 
management is not “in the direction of formal, formidable, massive documentation. 
It does, however, reside in the direction of creating a total environment which is 
conducive to the emergence and effective utilization of Creative and inventive talents 
oriented toward achieving a system approach with a minimum of management 
encumbrances.” 13 

According to the Merriam-Webster’s Dictionary, a process can be defined as “a 
series of actions or operations conducing to an end.” Is process the way a company 
operates — from marketing to human resources, to actual development — or the way 
a developer produces design or code, or tests the Software? Does the process refer 
to management, engineering, or both? Does process imply a lot of formalism and 
expanding effort for writing and reading documents, instead of product development? 
The best answer is that it depends on the situation. A “one size fits all” approach 
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does not work when defining processes. One would hardly expect to find the same 
processes used in a startup e-commerce company as in NASA. The intended goal 
shapes a process in terms of scope (namely, the stages and activities covered) and 
organizational level. Depending on the perspective, processes are defined for entire 
organizations, teams, or an individual. In any case, the process should help by guiding 
people on what to do — on how to divide and coordinate the work — and by ensuring 
effective communication. Coordination and communication, for example, form the 
main problems in large projects involving many people — especially in distributed 
projects where people cannot communicate face to face . 14 

For a given organizational level, the process varies with the project ’s goals and available 
resources. At a high level, the company’s business strategy determines the business 
approach. The main goals of time to market, minimum cost, or higher quality and 
customer satisfaction set the priorities. The company’s size; the number, knowledge, and 
experience of people 15 (both engineers and support personnel); and hardware resources 
determine how to achieve the goal. The application domain and the corresponding system 
requirements together with other constraints form another main factor. The space shuttle 
or nuclear plant control Software embedded in a complex system have different safety 
and reliability constraints than a word processor running on a PC; Software for a car has 
different time response constraints than a payroll system. 

Whenever someone (be it an individual or a company) wants to reach a desired end, 
they must perform a series of actions or operations. They must consider the order 
of these actions, their dependencies, who will perform them, what they require and 
what they will generate, how long it will take to complete them, and what tools they 
will employ. Thus, they do follow a process, be it predefined or ad hoc. Because all 
these process components (activities, products, agents, tools) and their interactions 
(information flow, artifacts flow, control, communication, timing, dependencies, 
and concurrency) can vary, processes will differ — even if they have the same level, 
scope, and goal. 

So why should an organization care about processes ? 16 To understand, evaluate, 
control, learn, communicate, improve, predict, and certify the work performed. What 
can organizations do to processes? They can document, define, measure, analyze, 
assess, compare, and change them. But the most difficult question of all is, “What is 
best for my organization?” That answer may be contained in this handbook. 

3.5 Introduction to three cases 

Real-world examples are provided throughout this handbook. They draw from 
diverse industries and types of systems. Three case studies have been selected used 
to illustrate the diversity of systems to which systems engineering principles and 
practices can be applied; medical therapy equipment, a bridge, and a super-high-speed 
train. They represent examples of failed, successful, and prototype systems that all 
define(d) the state-of-the-art. They may be categorized as medicine, infrastructure 
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and transportation applications; in the manufacturing and construction industry 
domains; with and without Software elements; complex; and subject to scrutiny both 
in the development and utilization stages as all have a need to be safe for humans and 
are constrained by government regulations. 

3.5.1 Case 1: Radiation Therapy; the Therac-25 

Therac-25, a dual-mode linear medical accelerator was developed by the medical 
division of Atomic Energy Commission Limited (AECL) of Canada, starting in 
1976. The completely computerized system became commercially available in 1982. 
This new machine could be built at lower production cost, resulting in lower prices 
for the customers. A series of tragic accidents led to the recommended recall, and 
discontinuation of production of the system. 

Summary of product features and history 

The Therac-25 was a medical linear accelerator. A linear accelerator (LINAC) is a 
particle accelerator, capable of increasing the energy of electrically charged atomic 
particles. The charged particles are accelerated by the introduction of an electric 
field, producing beams of particles, or radiation, which are then focused by magnets. 
LINACS are used to treat cancer patients by exposing malignant cells to radiation. 
Since malignant tissues are more sensitive than normal tissues to radiation exposure, a 
treatment plan can be developed that permits the absorption of an amount of radiation 
that is fatal to tumors but causes relatively minor damage to surrounding tissue. 

Therac-25 was a revolutionary design comparing to its predecessors, Therac- 
6 and Therac-20, both with exceptional safety records. It was based on a double- 
pass concept that allowed a more powerful accelerator to be built into a compact 
and versatile machine. AECL designed Therac-25 to fully utilize the potential of 
Software control. While Therac-6 and Therac-20 were built as stand-alone machines 
and could be operated without a Computer, Therac-25 depended on a tight integration 
of Software and hardware. In the new, tightly coupled system, AECL used Software 
to monitor the State of the machine and to ensure its proper operations and safety. 
Previous versions had included independent circuits to monitor the status of the beam 
as well as hardware interlocks that prevented the machine from delivering doses of 
radiation that were too high, or from performing any unsafe operation that could 
potentially harm the patient. In Therac-25, AECL decided not to duplicate these 
hardware interlocks since Software already performed status checks and handled all 
the malfunctions. This meant that the Therac-25 Software had far more responsibility 
for safety than the Software in the previous models. If in the course of treatment, the 
Software detected a minor malfunction it would pause the treatment. In this case, the 
procedure could be restarted by pressing a single “proceed” key. Only if a serious 
malfunction was detected was it required to completely reset the treatment parameters 
in order to restart the machine. 
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Software for Therac-25 was developed from the Therac-20’s Software, which was 
developed from the Therac-6’s Software. One programmer, over several years, evolved 
the Therac-6 Software into the Therac-25 Software. A stand-alone real-time operating 
system was added along with application Software written in assembly language and 
tested as a part of the Therac-25 system operation. In addition, significant adjustments 
had been made to simplify the operator interface and minimize data entry, since 
initial operators complained that it took too long to enter a treatment plan. 

At the time of its introduction to market in 1982, Therac-25 was classified as a Class 
II medical device. Since the Therac-25 Software was based on Software used in the 
earlier Therac-20 and Therac-6 models, Therac-25 was approved by the Federal Drug 
Administration under Pre-Market Equivalency. 

Six accidents involving enormous radiation overdoses to patients took place between 
1985 and 1987. Tragically, three of these accidents were the direct cause of the death 
of the patient. This case is ranked in the top ten worst software-related incidents on 
many lists. Details of the accidents and analysis of the case is available from many 
sources. 17 - 18,19 

3.5.2 Case 2: Joining two countries; the 0resund Bridge 

The Oresund Region is composed of eastern Denmark and Southern Sweden and 
since 2000 is linked by the 0resund Bridge. The area includes the two major cities 
Copenhagen and Malmo, has a population of 3 million, and counts as Europe’s eight 
largest economic center. One fifth of the total Danish and Swedish GN P (Gross National 
Product) is produced in the region. The official name of the bridge is translated “the 
Oresund Connection” to underscore the full integration of the region. For the first 
time ever, Sweden is joined permanently to the mainland of Europe by a 10-minute 
drive or train ride. The cost for the entire Oresund Connection construction was 
calculated at 30.1 billion DKK the investment expected to be paid back by 2035. 

The Oresund Bridge is the world’s largest composite structure, has the longest cable- 
stayed bridge span in the world carrying motorway and railway traffic, and boasts the 
highest freestanding pylons. The 7.9 km (5 mi) long bridge crosses the international 
navigation route between the Baltic Sea and the North Sea. A cable-stayed high bridge 
rises 57 m (160 feet) above the surface of the sea, with a main span of 490 m (0.3 
miles). Both the main span and the approach bridges are constructed as a two-level 
composite steel-concrete structure. The upper deck carries a four-lane motorway, 
and the lower deck carries a two-track railway for both passenger trains and freight 
trains. The rest of the distance is spanned by the artificial island Peberholm (“Pepper” 
islet, named to complement the Saltholm islet to the north) and a tunnel on the Danish 
side that is the longest immersed concrete tunnel in the world. Since completion, 
Peberholm has become a natural habitat for colonies of rare birds, one of the largest 
of its kind in Denmark and Sweden. 
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Nations other than Denmark and Sweden also contributed to this project. Canada 
provided a floating crane, aptly named Svanen (the swan), to carry prefabricated 
bridge sections out to the site and place them into position. Forty-nine Steel girders 
for the approach bridges were fabricated in Cadiz, Spain. A specially designed 
catamaran was built to handle transportation of the foundations for the pylons, which 
weighed 19,000 tons each. 

The project began with well-defined time, budget, and quality constraints. The design 
evolved over more than seven years, from start to delivery of final documentation and 
maintenance manuals. More than 4000 drawings were produced. The consortium 
dealt with changes as necessary using a combination of technical competence and 
stakeholder cooperation. Notably, there were no disputes and no significant claims 
against the owners at the conclusion and this has been attributed to the spirit of 
partnership. 

From the beginning, the owners defined comprehensive requirements and provided 
definition drawings as part of the contract documents, to ensure a project result that not 
only fulfilled the quality requirements on materials and workmanship, but also had the 
envisioned appearance. The contractor was responsible for the detailed design and for 
delivering a quality assured product in accordance with the owners’ requirements. 

Selected Requirements 

The following are representative of the requirements levied at the start of the 
project: 

Schedule: Design life 100 years; Construction time Apr. 1996 - Apr. 2000 
Railway: Rail load UIC 71; Train speed 200 km/h 
Motorway: Road axle load 260 kN; Vehicle speed 120 km/h 
Ambient environment: 

Wind speed (10 min) 61 m/s; Wave height 2.5 m; Ice thickness 0.6 m; Temperature 
+/- 27 °C 

Ship impact: to pylons 560 MN; to girder 35 MN 

Constraints 

In addition to established requirements, this project crossed national boundaries and 
was thereby subject to the legislations of each country. Technical requirements were 
based on the Eurocodes, with project specific amendments made to suit the national 
standards of both countries. Special safety regulations were set up for the working 
conditions, meeting the individual safety standards of Denmark and Sweden. 

The railway link introduced yet another challenge. In Denmark, the rail traffic is 
right handed as on roadways, whereas the trains in Sweden pass on the left hand 
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side. The connection needed to ensure a logical transition between the two Systems, 
including safety aspects. In addition, the railway power supply differs between the 
two countries, thus it was necessary to develop a system that could accommodate 
power supply for both railway systems. 

Bridge Design involves many disciplines 

The design of a major cable-stayed bridge with approach spans for both road and 
railway traffic involves several disciplines as illustratedby thispartial list: geotechnical 
engineering; aerodynamics; foundation engineering; wind tunnel tests; design of piers 
and pylons; design of composite girders; design of cables and anchorages; design of 
structural monitoring system; ship impact analysis; earthquake analysis; analysis of 
shrinkage and creep of concrete; ice loads analysis; fatigue analysis; pavement design; 
mechanical systems; electrical systems; comfort analyses for railway passengers; 
traffic forecast; operation and maintenance aspects; analysis of construction stages; 
risk analysis for construction and operation; quality management; and environmental 
studies and monitoring. 

Risk Management 

Comprehensive risk analyses were carried out in connection with the initial planning 
studies, including specification of requirements to secure all safety aspects. Important 
examples of the results of these studies for the 0resund Bridge were: 

• Navigation span was increased from 330 m to 490 m 

• Realignment and deepening of the navigation channel to reduce groundings 

• Introduction of pier protection islands 

Risks were considered in a systematic way, using contemporary risk analysis methods 
such as functional safety analyses using fault tree and “what if ’ techniques. Three 
main issues were considered under the design-build contract: 

• General Identification and assessment of construction risks 

• Ship collision in connection with realignment of navigation channel 

• Risks in connection with 5 years bridge operation by contractor 

A fully quantified risk assessment of the human safety and traffic delay risks was 
carried out for a comprehensive list of hazards including: fire; explosion; train 
collisions and derailments; road accidents; ship collisions and groundings; aircraft 
collisions; environmental loads beyond design basis; and, toxic spillages. An example 
of a consequence of this analysis was the provision of passive fire protection on the 
tunnel walls and ceilings. 
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Environmental Considerations 

Both Denmark and Sweden are proud of being among the cleanest industrial countries 
in the world. Their citizens, and therefore the politicians, would not allow for any 
adverse environmental impact from the construction or operation of a bridge. The 
Great Belt and 0resund Strait both constitute corridors between the salty Kattegat 
and the sweeter water of the Baltic Sea. Any reduction in water exchange would 
reduce the salt content, and, therefore, the oxygen content, of the Baltic Sea and 
would alter its ecological balance. The Danish and Swedish Authorities decided that 
the bridge should be designed in such a way that the flow-through of water, salt and 
oxygen into the Baltic was not affected. This requirement was designated the zero 
solution. In order to limit impacts on the local flora and fauna in 0resund during 
the construction, the Danish and Swedish authorities imposed a restriction that the 
spillage of seabed material from dredging operations should not exceed 5% of the 
dredged amounts. The zero solution was obtained by modeling with 2 different and 
independent hydrographical models. 

In total, 18 million cubic meters of seabed materials were dredged. All dredged 
materials were reused for reclamation of the artificial peninsula at Kastrup and 
the artificial island, Peberholm. A comprehensive and intensive monitoring of the 
environment was performed in order to ensure and document the fulfillment of all 
environmental requirements. In their final status report from 2001 the Danish and 
Swedish Authorities concluded that the zero solution as well as all environmental 
requirements related to the construction of the link had been fulfilled. Continual 
monitoring of eel grass and common mussels showed that, after a general but minor 
decline, populations had recovered by the time the bridge was opened. Overall, the 
environment paid a low price at 0resund and the Great Belt, because it was given 
consideration throughout the planning and construction phases of the bridges. 

This award-winning bridge is the subject of numerous articles and a PhD thesis, 
where details of the construction history and collaboration among all the stakeholders 
are provided. 20,21,22 

3.5.3 Case 3: Prototype system; The Super-high-speed train in China 

Shanghai Transrapid is the first commercial high-speed commuting system using 
the state-of-the-art electromagnetic levitation (or maglev) technology. The train runs 
from Shanghai’s financial district to Pudong International Airport, and the total track 
length is about 30 kilometers (20 miles). The train takes 7 minutes and 20 seconds to 
complete the journey, and can reach almost 200 mph (320 km/h) in 2 minutes, and 
reaches its maximum speed of 267 mph (430 km/h) within 4 minutes. The Shanghai 
Transrapid project took 1.2 billion USD (10 billion Yuan) and 2.5 years to complete 
the track. Construction began in March 2001, and public Service commenced on 
January 1, 2003. Critics argue that the speed over such a short distance is unnecessary 
and that the line may never recoup this cost. 
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Prior to this installation, many countries had argued over the feasibility of maglev 
trains. They do not have wheels or use a traditional rail. Rather, powerful magnets 
lift the entire train about 10 millimeters above the special track, called a guideway, 
since it mainly directs the passage of the train. Electromagnetic force is used 
to make the train hover, and to provide vertical and horizontal stabilization. The 
frequency, intensity and direction of the electrical current in the track control the 
train’s movement, while the power for the levitation system is supplied by the train’s 
onboard batteries, which recharge whenever the train is moving. Maglev trains also 
do not have an onboard motor. The guideway contains a built-in electric motor that 
generates an electromagnetic field that pulls the train down the track. Putting the 
propulsion system in the guideway rather than onboard the trains, makes the cars 
lighter, which enables the train to accelerate quickly. The super-high speeds are 
attained largely due to the reduction of friction. 

Despite the high speed, the maglev system runs more quietly than a typical commuter 
train, consumes less energy and is nearly impossible to derail because of the way 
the train’s underside partially wraps around the guideway, like a giant set of arms 
hugging the train to the elevated platform. Passengers experience a comfortable and 
quiet ride due to the maglev technology and the specially designed window; noise 
level is less than 60 decibels at a speed of 300 km/h. 

The Chinese authorities considered the economical operation, low energy 
consumption, less environmental impact, and high speed when choosing a solution 
suitable for ground transport between hubs that range from hundreds to over one 
thousand kilometers apart. But the same solution also needed to be suitable for modern 
mass rapid passenger transportation between a center city and adjacent cities. Despite 
the many advantages, in 1999 the technology was considered to be in an experimental 
stage, not yet proven by commercialized operation, its technological superiority, safety 
and economic performance remaining to be proved. The current line is the result of 
a compromise; it was built as a demonstration to verify the maturity, availability, 
economics and safety of a high speed maglev transportation system. 

The basic technology to create a maglev system has been around since 1979, but until 
this project it had never been realized - mostly due to the expense of developing a 
new train system. Many experts believe that super-fast steel-wheel rail systems - such 
as those in France and Japan - have reached the limits of this technology and can 
not go any faster. Maglev proponents describe the system as “the first fundamental 
innovation in the field of railway technology since the invention of the railway” and 
are watching proposals for maglev installations in Germany and the USA. 23 ’ 24,25 ’ 26 


1 Used with permission of H. Stoewer 

2 ISO/IEC 15288, Table D-l, page 57 

3 Figure provided by Kevin Forsberg, CSM. 
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4 Technical Processes 


4.1 Introduction 

The ISO/IEC 15288 technical processes are invoked throughout the life cycle stages 
of a system. Technical processes are used to establish requirements for the system 
as the basis for the efforts to create an effective product or Service; to sustain the 
system through its useful life; and to support retirement of the system. Figure 1-1 
illustrates the relationship of the technical processes to the Agreement, Enterprise 
and Project Processes. Without the technical processes, the risk of project failure 
would be unacceptably high. In his opening keynote at the 15th Annual INCOSE 
International Symposium, Riley Duren of Jet Propulsion Laboratory, California, 
stressed that systems engineering is a way of thinking about and solving challenges 
and that systems engineers are the GLUE that hold the elements of complex space 
programs together. To achieve good results, systems engineers involve themselves in 
nearly every aspect of a project, pay close attention to interfaces where two or more 
systems or system elements work together, and establish an interaction network with 
stakeholders and other organizational units of the enterprise. Figure 4-1 shows the 
critical interactions for systems engineers. 


Ref. Prof H Stoewer 


SYSTEM ENGINEERING ENVIRONMENT 



Figure 4-1 Context of Systems Engineering Technical Processes' 

Technical processes enable systems engineers to coordinate the interactions between 
engineering specialists, systems stakeholders and operators, and manufacturing. 
They also address conformance with the expectations and legislated requirements of 
society. These processes lead to the creation of a full set of requirements that address 
the desired capabilities within the bounds of performance, environment, external 
interfaces, and design constraints. 


Page 4.1 of 24 

Copyright ©2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. 


INCOSE-TP-2003-002-03 
June 2006 


INCOSE Systems Engineering Handbook v. 3 


4.2 Stakeholder Requirements Definition Process 

4.2.1 Purpose 

The purpose of the Stakeholder Requirements Definition Process is to elicit, negotiate, 
document, and maintain stakeholders’ requirements for the system-of-interest within 
a defined environment. 

4.2.2 Description 

A stakeholder is any entity (individual or organization) with a legitimate interest 
in the system. Typical stakeholders include operators, enterprise decision-makers, 
parties to the agreement, regulatory bodies and society-at-large. When direct contact 
is not possible, Systems engineers find agents, such as marketing or non-governmental 
organizations to represent the concerns of a class of stakeholders, such as consumers, 
or future generations. 

The Stakeholder Requirements govern the system’s development; and they are an 
essential factor in further defining or clarifying the scope of the development project. 
If an enterprise is acquiring the system, this process provides the basis for the technical 
description of the deliverables in an agreement - typically in the form of a system- 
level specification and defined interfaces at the system boundaries. In the next process 
(Requirements Analysis Process), the verification criteria are added to this definition. 
Requirements management is the subject of a section in Chapter 7. Figure 4-2 is the 
context diagram for this process. 



Figure 4-2 Context Diagram for Stakeholder Requirements Definition Process 

4.2.3 Inputs 

The inputs to this process include the description of users’ needs or Services that the 
system will provide, cost, schedule, and solution constraints, terms and conditions of 
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the agreement, and industry specifications and standards. This process is governed 
by project plans and enterprise standards, guidelines, policies, procedures, and 
reporting mechanisms. 

4.2.4 Outputs 

The outputs of this process consist of formally documented and approved stakeholder 
requirements that will govern the project, including: required system capabilities, 
functions and/or Services; quality standards; cost and schedule constraints; concept 
of operations; and concept of support. The outputs should include measures of 
effectiveness and suitability that will be used for assessing the realized system 
and enabling systems. Validation criteria may specify who will perform validation 
activities, and the environments of the system-of-interest and enabling systems. Other 
outputs establish the initial baseline for project scope and associated agreements. The 
following are instances of concept documentation: 

• Concept ofProduction describes the way the system will be manufactured. 

• Concept of Deployment describes the way the system will be delivered and 
installed. 

• Concept of Operations describes the way the system works from the operator’s 
perspective. 

• Concept of Support describes the desired support infrastructure and 
manpower considerations for maintaining the system after it is deployed. This 
includes specifying equipment, procedures, facilities and operator training 
requirements. 

• Concept of Disposal describes the way the system will be removed from 
operation and retired. 

4.2.1 Process Activities 

This process includes the following activities: 

• Identify stakeholders who will have an interest in the system throughout its 
entire life cycle. 

• Elicit system Services and capabilities - what the system must accomplish and 
how well. 

• Identify constraints imposed by agreements or interfaces with legacy enabling 
systems. 

• Establish critical and desired system performance - thresholds and objectives 
for system performance parameters that are critical for system success and 
those that are desired but may be subject to compromise in order to meet the 
critical parameters 

• Establish measures of effectiveness and suitability - measures that reflect overall 
customer/user satisfaction (e. g. performance, safety, reliability, availability, 
maintainability, and workload requirements). 
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• Analyze requirements for clarity, completeness and consistency. 

• Negotiate modifications to resolve unrealizable or impractical requirements. 

• Establish a traceability matrix to document how the formal requirements 
are intended to meet the stakeholder objectives and achieve stakeholder 
agreement. 

• Record and maintain stakeholder requirements throughout the system life 
cycle, and beyond for historical or archival purposes. 

■ Common approaches and tips: 

• Use scenarios to define the concept documents - bound the range of anticipated 
uses of system products, the intended operational environment and interfacing 
Systems, platforms or products. Scenarios help identify requirements that might 
otherwise be overlooked. Social and organizational influences also emerge 
from using scenarios. 

• Once established, the stakeholders’ requirements are placed under configuration 
control. 

• Establish good relationships and open Communications between systems 
engineers and stakeholders. This is helpful when negotiations begin to refine 
and clarify the set of requirements. 

• Identify all stakeholders; it is critical to identify and include key system 
stakeholders in this process including the development/design team. 

• Avoid designing a final solution or establishing unjustified constraints on the 
solution. 

• Avoid acceptance of unrealistic or competing objectives. 

• Write clearly and create statements with quantifiable values . 2 

• Capture source and rationale for each requirement . 3 


4.3 Requirements Analysis Process 

4.3.1 Purpose 

The purpose of the Requirements Analysis Process is to review, assess, prioritize, 
and balance all stakeholder and derived requirements (including constraints); and 
to transform those requirements into a functional and technical view of a system 
description capable of meeting the stakeholders’ needs. This view can be expressed 
in a specification, set of drawings or any other means that provides effective 
communication. 
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4.3.2 Description 

Requirements analysisisan interim process: the outputoftheprocessmustbecompared 
for traceability and consistency with the Stakeholder Requirements, before being 
used to drive the Architectural Design Process, without introducing implementation 
biases. Figure 4-3 is the context diagram for Requirements Analysis. 



Figure 4-3 Context Diagram for the Requirements Analysis Process 

4.3.3 Inputs 

The primary input to the Requirements Analysis Process is the baseline documented 
during the Stakeholder Requirements Definition Process. Additional inputs to the 
Requirements Analysis Process include applicable statutes, regulations, and policies; 
the intended operational use and utilization environment for the system; any design 
or enterprise constraints; manufacturing; life cycle support considerations; design 
considerations (e. g. applicable standards, environmental and safety concerns, etc.); 
and any decisions or data resulting from previous phases of development. 

4.3.4 Outputs 

The output of Requirements Analysis is a technical description of characteristics the 
future system must have in order to meet Stakeholder Requirements - not a specific 
solution - which will be evolved in subsequent development processes. The project 
team derives additional requirements resulting from analysis of the input Stakeholder 
Requirements as required to meet project and design constraints; defines the 
functional boundaries for the system to be developed; and identifies and documents 
any interfaces and information exchange requirements with systems external to the 
functional boundaries. The total set of requirements encompasses the functional, 
performance, and non-functional requirements and the architectural constraints. Any 
decisions taken are documented in the information repository. 
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4.3.5 Process Activities 

Titis process includes the following activities: 

• Define and specify the functional boundary and performance. This will specify 
what the system should be able to do (functional requirements) when fielded 
and operated in its intended operating environment. The levels and measures of 
performance (MOP) for the top-level system functional requirements required 
to satisfy the system Measures of Effectiveness (MOE) are determined from 
the following: 

• Selected Standards - identify standards required to meet quality or design 
considerations imposed as defined stakeholder requirements or derived to meet 
enterprise, industry, or domain requirements 

• System Boundaries - clearly identify system elements under design control 
of the project team and/or enterprise and expected interactions with systems 
external to that control boundary 

• External Interfaces - functional and design interfaces to interacting systems, 
platforms, and/or humans external to the system boundary 

• Utilization Environment(s) - identify all environmental factors (natural or 
induced) that may affect system performance, impact human comfort or safety, 
or cause human error for each of the operational scenarios envisioned for 
system use 

• Life Cycle Process Requirements - conditions or design factors that facilitate 
and foster efficient and cost-effective lifecycle functions (i. e. Production, 
Deployment, Transition, Operation, Maintenance, Reengineering/Upgrade, 
and Disposal) 

• Design considerations - including human-systems integration (manpower, 
personnel, training, human factors, safety), system security requirements (e.g. 
information assurance, anti-tamper provisions), and potential environmental 
impact 

• Design constraints - including physical limitations (e.g. weight, form/fit factors) 
and defined interfaces with interacting systems and host platforms external to 
the system boundary 

• Define Verification Criteria - concurrent with analysis, to ensure verifiable 
requirements 

• Maintain continuity of configuration control and traceability. 

■ Common approaches and tips: 

• lntegrated Product Teams (with acquirer-supplier participation) are an effective 
practice to bring together the necessary expertise. 4 

• Use failure modes, effects, and criticality analysis (FMECA) or hazard analysis 
to identify the critical system level requirements. See chapters 7 and 9 for 
additional discussion about identifying the non-functional requirements. 

• Use specially designed requirements management tools. 5 

• Begin from the very beginning to maintain requirements traceability. 
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• Avoid deriving requirements that are not consistent with other requirements or 
constraints. 

• Create templates for constructing requirements statements. 6 


4.4 Architectural Design Process 

4.4.1 Purpose 

The purpose of the Architectural Design Process is to synthesize a system solution 
that satisfies the requirements. 

4.4.2 Description 

The Architectural Design Process requires the participation of Systems engineers 
joined by relevant specialists in the system domain. When alternative Solutions 
present themselves, technical analysis and decisions are taken as part of this process 
to identify a set of system elements. Integration is defined for the system, not the 
individual system elements. Figure 4.4 is the context diagram for the Architectural 
Design Process. 



Figure 4-4 Context Diagram for the Architectural Design Process 

4.4.3 Inputs 

Architectural design begins from the baseline functional and performance 
requirements, architectural constraints, and traceability matrix. Specifications for 
enabling systems are used to drive interface design. Specifications for reusable 
system elements are used when designing for product lines. 
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4.4.4 Outputs 

The result of this process is an architectural design that is placed under configuration 

management. This baseline includes: 

• System element detailed descriptions 

• Requirements assigned to system elements and documented in a traceability 
matrix 

• Interface requirements and a plan for system integration and verification 
strategy 

4.4.5 Process Activities 

The following processes contribute to architectural design: 

• Define a consistent logical architecture - capture the logical sequencing and 
interaction of system functions or logical elements 

• Partition system requirements and allocate them to system elements with 
associated performance requirements - consider off-the-shelf Solutions that 
already exist. 

• Evaluate alternative design Solutions - see chapter 7 for a discussion of trade 
studies 

• Identify interfaces between system elements and with external and enabling 
systems 

• Define the system integration strategy. 

• Document and maintain the Architectural Design and relevant decisions made 
to reach agreement on the baseline design. 

• Establish and maintain the traceability between requirements and system 
elements. 

• Define Verification and Validation Criteria for the system elements. 

■ Common approaches and tips: 

• Modeling techniques such as SysML, discussed in chapter 7, are useful in 
deriving a logical architecture. 

• Use an Integrated Product Team for analysis and review; working together as a 
team helps break down Communications silos and facilitates decision-making. 

• Architecture and Design Patterns can be useful for establishing a system 
framework. 

• System elements can be developed in a top-down partitioning exercise that 
allocates the functional elements to physical or virtual system elements. 
Ideally, interface requirements between these system elements are minimized. 
At the same time, off-the-shelf or previously developed system elements are 
considered within the constraints of the contracting strategy. 

• During this process, consider emergent properties, feature interactions, and 
human-machine interactions. 7 
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4.5 Implementation Process 

4.5.1 Purpose 

The purpose of the Implementation Process is to design, create or fabricate a system 
element conforming to that element’s detailed description. The element is constructed 
employing appropriate technology and industry practices. This process straddles the 
Development and Production stages. 

4.5.2 Description 

During the Implementation Process, engineers follow the requirements allocated 
to the system element to design, fabricate, code, or build each individual element 
using specified materials, processes, physical or logical arrangements, standards, 
technologies, and/or information flows outlined in detailed drawings or other design 
documentation. Requirements are verified and stakeholderrequirements are validated. 
If subsequent configuration audits reveal discrepancies, recursive interactions occur 
with predecessor activities or processes as required to correct them. Figure 4-5 is the 
context diagram for the Implementation Process. 



Figure 4-5 Context Diagram for the Implementation Process 


4.5.3 Inputs 

The system element requirements and the associated verification and validation criteria 
are input to this process from the Architectural Design Process. Execution of the 
Implementation Process is governed by 

• government and industry standards, terms of any agreements 

• conditions of the agreement for packaging, storage, and initial operator training 
(PHS&T) - see discussion of PHS&T in Chapter 9 

• enterprise safety practices and other guidelines 
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4.5.4 Outputs 

Outputs from this process include: 

• Refined Implementation Strategy and Integration Constraints 

• System element - verified and validated - supplied according to agreement 

• Detailed drawings and codes and material specifications 

• Updated design documentation - as required by corrective action or adaptations 
caused by acquisition or conformance to regulations 

• Operator/Maintenance training manuals and initial staff of trained users and 
maintainers according to agreement 

4.5.5 Process Activities 

Implementation Process activities begin with detailed design and include developing 
an Implementation Strategy that defines fabrication/coding procedures, tools and 
equipment to be used, implementation tolerances, and the means and criteria for 
auditing configuration of resulting elements to the detailed design documentation. In 
the case of repeated system element implementations (such as for mass manufacturing 
or replacement elements) the implementation strategy is defined/refined to achieve 
consistent and repeatable element production; and it is retained in the project 
decision database for future use. As required, data for training users on correct 
and safe procedures for operating and maintaining that element — either as a stand- 
alone end item or as part of a larger system — are developed and added to the project 
database. Detailed product, process, material specifications (“Build-to” or “Code-to” 
documents) and corresponding analysis are completed. 

• Conduct peer reviews and unit testing - inspect and test Software for correct 
functionality, white box testing, etc. in accordance with software/hardware 
best practices 

• Conduct hardware conformation audits - compare hardware elements to detailed 
drawings to assure that each element meets its detailed specifications prior to 
integration with other elements in higher configuration items or assemblies 

• Draft training documentation - to support operating, conducting failure detec- 
tion and isolation, and maintaining system components, subsystems, and the 
system as appropriate 

• Train initial operators and maintainers - on the use of elements that provide a 
human-system interface or require maintenance actions at the element level 

■ Common approaches and tips: 

• Keep the Integrated Product Team engaged to assist with configuration issues 
and redesign. 

• Inspections are a proactive way to build in quality. 8 

• In anticipation of improving process control, reducing production inspections, 
and lowering maintenance activities, many manufacturing firms use Design for 
Six Sigma, or Lean Manufacturing. 
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• Conduct hardware conformation audits or system element level hardware 
testing; ensure sufficient Software unit testing prior to integration. 

• Validate simulations; interface simulator drivers should be representative of 
tactical environments. 


4.6 Integration Process 

4.6.1 Purpose 

The purpose of the Integration Process is to realize the system-of-interest by 
progressively combining system elements in accordance with the architectural design 
requirements and the integration strategy. This process is successively repeated in 
combination with the Verification and Validation Processes as appropriate. 

4.6.2. Description 

The Integration Process includes activities to acquire or design and build enabling 
Systems needed to support the integration of system elements and demonstration 
of end-to-end operation. This process confirms all boundaries between system 
elements have been correctly identified and described, including physical, logical, 
and human-system interfaces; and confirms that all functional, performance, and 
design requirements and constraints are satisfied. Interim assembly configurations 
are tested to assure correct flow of information and data across interfaces to reduce 
risk, and minimize errors and time spent isolating and correcting them. Figure 4-6 is 
the context diagram for the Integration Process. 



Figure 4-6 Context Diagram for the Integration Process 
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4.6.3 Inputs 

Inputs for this process include: 

• Integration plan 

• Integration technology constraints 

• Enabling systems - Integration tools, facilities, and test equipment 

• Applicable system elements, interface, and assembly requirements 
specifications 

4.6.4 Outputs 

Outputs for this process include: 

• Integration test and analysis results, including areas of non-conformance 

• Updated interface requirements specifications 

• Validated internal interfaces 

• Completed subsystem or system ready for verification 

• Product assembly drawings and manufacturing tool drawings 

4.6.5 Process Activities: 

Activities in the Integration Process include: 

• Schedule Integration Testing Tools and Facilities 

• Assemble system elements according to the integration plan 

• Validate Interfaces - confirm correct flow of information across internal 
interfaces through “black box testing” at each successive level of assembly 

• Test and analyze Assemblies - confirm correct functionality of assembled 
products through integration testing and analysis at each successive level of 
assembly 

• Document integration testing and analysis results 

• Document and control the architectural baseline - this includes capturing any 
modifications required during this process 

■ Common approaches and tips: 

• Keep the Integrated Product Team engaged to assist with configuration issues 
and redesign. 

• Maintain configuration control over including drawings, specifications, 
interface control drawings, and published analyses. 

• Define an integration strategy that accounts for the schedule of availability 
of system elements, including human operators, and is consistent with fault 
isolation and diagnosis engineering practices. 
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4.7 Verification Process 

4.7.1 Purpose 

The purpose of the Verification Process is to confirm that all requirements are fulfilled 
by the system elements and eventual system-of-interest, i. e. that the system has been 
built right. This process establishes the procedure for taking remedial actions in the 
event of non-conformance. 

4.7.2 Content/Description 

The Verification Process confirms that all elements of the system-of-interest perform 
their intended functions and meet the performance requirements allocated to them. 
Verification methods include test, inspection, analysis, and demonstration and are 
discussed in more detail in chapter 8. Verification activities are determined by the 
perceived risks, safety, and criticality of the element under consideration. 

A key outcome of the Planning Process is the creation of project procedures and 
processes that specify the forms of system assessments (conformation audits, 
integration testing, verification, and validation) in appropriate project documents 
(e. g. Systems engineering plans, schedules, and specifications). Specification of 
verification criteria takes place as the requirements are written, but the creation of 
a procedure to assess compliance is part of this process. Figure 4-7 is the context 
diagram for the Verification Process. 



Figure 4-7 Context Diagram for the Verification Process 

4.7.3 Inputs 

Within the guidelines of enterprise policies and established project directives, 
system elements are verified against the baseline requirements and the information is 
maintained in a Requirements Verification Traceability Matrix. 
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4.7.4 Outputs 

The outputs of this process are documentation of the verification results, a record 
of any corrective actions recommended, Design Feedback/Corrective Actions taken, 
and evidence that the system element or system satisfies the requirements, or not. 

4.7.5 Process Activities 

The Verification Processes include: 

• Develop verification procedures 

• Schedule/confirm/install verification enabling systems 

• Execute verification procedures 

• Document verification results and enter data into traceability matrix 
■ Common approaches and tips: 

• The requirements verification traceability matrix is frequently used as a single 
point of accountability for tracing a requirement back to the source of the need 
and forward through the life cycle to assess that the need has been met. 

• Beware the temptation to reduce verification activities due to budget or schedule 
overruns - remember the message of Figure 2-3 - discrepancies and errors are 
more costly to correct later in the life cycle. 9 

• Avoid conducting verification late in the schedule when there is less time to 
handle discrepancies, or too early, before development is complete. 


4.8 Transition Process 

4.8.1 Purpose 

The purpose of the Transition Process is to transfer custody of the system and 
responsibility for system support from one organizational entity to another. This 
includes (but is not limited to) transfer of custody from the development team to 
the organizations that will subsequently operate and support the system. Successful 
conclusion of the Transition Process typically marks the beginning of the Utilization 
Stage of the system-of-interest. 

4.8.2 Description 

The Transition Process installs a verified system in the operational environment along 
with relevant enabling systems, such as, operator training systems, as defined in the 
agreement. As part of this process, the acquirer accepts that the system provides the 
specified capabilities in the intended operational environment prior to allowing a 
change in control, ownership, and/or custody. While this is a relatively short process, 
it should be carefully planned to avoid surprises and recrimination on either side 
of the agreement; and transition plans should be tracked and monitored to ensure 
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all activities are completed to both parties’ satisfaction. Figure 4-8 is the context 
diagram for the Transition Process. 
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Figure 4-8 Context Diagram for the Transition Process 

4.8.3 Inputs 

Availability of the system-of-interest together with enabling systems is prerequisite to 
begin the Transition Process. Installation and commissioning of the system includes 
human operators, and is conducted according to agreements, and applicable health, 
safety, security and environmental regulations. 

4.8.4 Outputs 

At the conclusion of the Transition Process the system is installed, acceptance criteria 
are met or discrepancies documented with recommended and agreed corrective 
actions. 

4.8.5 Process Activities 

The Transition Processes include: 

• Prepare a transition strategy including operator training and logistics support. 

• Train the users in the proper use of the system; affirm users have the knowledge 
and skill levels necessary to perform Operation and Maintenance activities. 

• Receive final confirmation that the system — as operated and maintained by 
the intended users — meets their needs. This process typically ends with a 
formal, written acknowledgement that the system has been properly installed 
and verified, that all issues and action items have been resolved, and that all 
agreements pertaining to development and delivery of a fully supportable 
system have been satisfied fully or adjudicated. 
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• Post-implementation problems are documented and may lead to corrective 
actions or changes to the requirements. 

■ Common approaches and tips: 

• When acceptance activities can not be conducted within the operational 
environment, a representative locale is selected. 

• This process relies heavily on quality assurance and configuration management 
documentation. 


4.9 Validation Process 

4.9.1 Purpose 

The purpose of the Validation Process is to confirm that the realized system complies 
with the stakeholder requirements. System validation is subject to approval by the 
project authority and key stakeholders. This process is invoked during the Stakeholders 
Requirements Definition Process to confirm that the requirements properly reflect the 
stakeholder needs and to establish validation criteria, i. e. that the right system has 
been built. This process is also invoked during the Transition Process to handle the 
acceptance activities. 

4.9.2 Description 

The Validation Process performs a comparative assessment as a means to determine 
if stakeholders’ requirements and defined measures of effectiveness have been 
correctly translated into technical design specifications and measures of performance. 
Validation criteria are selected based upon the perceived risks, safety and criticality. 
Figure 4-9 is the context diagram for the Validation Process. 



Figure 4-9 Context Diagram for the Validation Process 
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4.9.3 Inputs 

When stakeholder requirements are elicited, validation criteria are applied before 

proceeding. After the system-of-interest is verified, it is subjected to the validation 

criteria. The previously established requirements traceability matrix is maintained. 

The activities are governed by the agreements, project procedures, and appropriate 

enterprise policies. 

4.9.4 Outputs 

The primary outputs of the Validation Process are 

• Validation activity results 

• Design feedback/corrective actions 

• Approved system baseline 

4.9.5 Process Activities 

The following activities are part of the Validation process. 

• Develop validation procedures that demonstrate that the system is fit for its 
purpose and satisfies the stakeholders’ requirements. 

• Ensure readiness to conduct validation - system, enabling systems, and trained 
operators. 

• Conduct validation to demonstrate conformance to stakeholder requirements. 

• Document validation results and enter data into traceability matrix 

• If anomalies are detected, analyze for corrective actions, detect trends in failure 
to find threats to the system and evidence of design errors. 

■ Common approaches and tips: 

• Validation methods during the concept phase include developing assessment 
scenarios exercising all system modes, and demonstrating system-level 
performance over the entire operating regime. The system design team uses 
the results of this activity to forecast success in meeting the expectations of 
users and the acquirer, as well as to provide feedback to identify and correct 
performance deficiencies before implementation . 10 


4.10 Operation Process 

4.10.1 Purpose 

The purpose of the Operation Process is to use the system to deliver its Services. This 
process is often executed concurrent with the Maintenance Process. 
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4.10.2 Description 

The Operation Process sustains system Services by supplying personnel to operate 
the system, monitoring operator-system performance, and monitoring the system 
performance. When the system replaces an existing system, it may be necessary 
to manage the migration between systems such that persistent stakeholders do not 
experience a breakdown in Services. 

The Operation Stage of a system usually accounts for the largest portion of the total 
life cycle cost. If system performance falls outside acceptable parameters, this may 
indicate the need for corrective actions, in accordance with the Concept of Support 
and any associated agreements. When the system or any of its constituent elements 
reach the end of their planned or useful life, the team may enter the Disposal Process. 
Figure 4-10 is the context diagram for the Operation Process. 



Figure 4-10 Context Diagram for the Operation Process 

4.10.3 Inputs 

The Operation Process identifies and analyzes operational performance in the context 
of agreements, stakeholder requirements and organizational constraints. Concept 
documents generated early in the life cycle are used to direct the activities of this 
process. 

4.10.4 Outputs 

Outputs of the Operation Process include: 

• Operational strategy - including staffing and sustainment of enabling systems 
and materials 

• System performance reports (statistics, usage data, and operational cost data) 
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• System trouble/anomaly reports with recommendations for appropriate action 

• Operational availability constraints - to influence future design and specification 
of similar systems or reused systems-elements 

4.10.5 Process Activities 

Activities of the Operation Process include: 

• Provide operator training 

• Track system performance and account for operational availability 

• Perform operational analysis 

• Manage operational support logistics 

• Document system status and actions taken 

• Report malfunctions and recommendations for improvement 

■ Common approaches and tips: 

• The Operations Process corresponds to a life cycle phase called the Utilization 
Stage. 

• Depending on the nature of agreements between different organizations, the 
development team may continuously or routinely communicate with users 
to determine the degree to which delivered Services continue to satisfy their 
needs. The system may exhibit unacceptable performance when system 
elements implemented in hardware have exceeded their useful life or changes 
in the operational environment affect system performance. In the event of 
system failures or anomalies, it may be necessary to conduct engineering 
investigations to identify the source(s) of the failure and determine appropriate 
corrective actions. Systems engineers can assist in these activities. 


4.11 Maintenance Process 

4.11.1 Purpose 

The purpose of the Maintenance Process is to sustain the system through its useful 
life. 

4.11.2 Description 

The Maintenance Process includes the activities to provide operations support, 
logistics, and material management. Based on feedback from ongoing monitoring 
of the operational environment, problems are identified and corrective, remedial 
or preventive actions are taken to restore full system capability. This process also 
contributes to the Requirements Analysis Process when considerations of constraints 
imposed in later life cycle stages are used to influence the system requirements and 
architectural design. 
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Figure 4-11 Context Diagram for the Maintenance Process 

4.11.3 Inputs 

The Maintenance Process identifies and analyzes maintenance and support activities 
in the context of agreements, stakeholder requirements and organizational constraints. 
Concept documents generated early in the life cycle are used to direct the activities 
of this process. 

4.11.4 Outputs 

The following are outputs of the Maintenance Process. 

• Maintenance strategy - accounts for the system’s technical availability, 
replacements for system elements and logistical support, maintenance personnel 
training and staff requirements 

• Maintenance constraints (to influence system requirements before design) 

• Reporting of failures and recommendations for action 

• Failure and lifetime performance data 

4.11.5 Process Activities 

The following activities occur under the Maintenance Process. 

• Establish a maintenance strategy 

• Define maintenance constraints on system requirements 

• Obtain the enabling systems, system elements and other Services used for 
maintenance of the system, monitor replenishment levels of spare parts, and 
manage the skills and availability of trained maintenance personnel 

• Implement problem reporting and resolution procedures - including scheduled 
replacement of system elements prior to failure (preventive maintenance) 

• Maintain a history of failures, actions taken, and other trends to inform 
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operations and maintenance personnel, and other projects creating or utilizing 
similar system elements 

• Monitor customer satisfaction with system and maintenance support 
■ Common approaches and tips: 

• The Maintenance Process corresponds to a life cycle phase called the Support 
Stage. 

• Use historic data and performance statistics to maintain high levels of reliability 
and availability; and provide input to improve the design of operational and 
future systems. 

• Planning for Maintenance begins early in the system life cycle with the 
development of supportability criteria. These criteria, which include reliability 
and maintainability requirements as well as personnel, training, facilities, etc. 
are included in the defined stakeholder requirements or system specification 
to ensure that they are considered in the system design. Chapter 9 contains a 
detailed discussion of acquisition logistics. 

• Maintain configuration management control throughout the Utilization and 
Support Stages in support of the Maintenance Process. 


4.12 Disposal Process 

4.12.1 Purpose 

The purpose of the Disposal Process is to remove a system element from the 
operational environment with the intent of permanently terminating its use; and to 
deal with any hazardous or toxic materials or waste products in accordance with 
applicable guidance, policy, regulations, and statutes. 

4.12.2 Description 

This process is implemented in the Disposal Stage, but Disposal is a life cycle support 
process because concurrent consideration of disposal during the Development 
Stage generates requirements and constraints that must be balanced with defined 
stakeholders’ requirements and other design considerations. Environmental concerns 
are driving the designer to consider reclaiming the materials or recycling them into 
new systems. Regulatory reporting requirements are addressed by this process. 
Figure 4-12 is the context diagram for the Disposal Process. 
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Figure 4-12 Context Diagram for the Disposal Process 

4.12.3 Inputs 

The Disposal Process works on a depleted system or system elements (for example, 
batteries) and implements the disposal plan according to applicable environmental 
laws, regulations, and policy. Stakeholder agreements and industry standards 
for disposal can also govern decision-making for this process. If production and 
operational environments must be restored to former conditions, details of the initial 
State are relevant. 

4.12.4 Outputs 

The first application of the Disposal Process results in a set of constraints on the 
system requirements and a strategy for disposal of the system and relevant system 
elements. The outcome from retirement or disposal may include an inventory of 
system elements for reuse/storage, and any documentation required by regulation or 
enterprise standards. 

4.12.5 Process Activities 

As required, Disposal Process activities include deactivating the elements to be 
terminated; disassembling the elements for ease of handling; removing the elements 
and any associated waste products from the operational site; removal of materials 
from storage sites; and consigning the elements and waste products for destruction 
or permanent storage. The Disposal Process also includes any steps necessary to 
return the environment to an acceptable condition; handling all system elements and 
waste products in an environmentally sound manner in accordance with applicable 
legislation, organizational constraints, and stakeholder agreements; and documenting 
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and retaining records of Disposal activities as required for monitoring by external 
oversight or regulatory agencies. 

■ Common approaches and tips: 

• The project team conducts analyses to develop Solutions forultimate disposition 
of the system, constituent elements, and waste products based on evaluation 
of alternative disposal methods available. Methods addressed should include 
storing, dismantling, reusing, recycling, reprocessing and destroying end 
products, enabling systems, system elements, and materials. 

• Disposal analyses include consideration of costs, disposal sites, environmental 
impacts, health and safety issues, responsible agencies, handling and 
shipping, supporting items, and applicable federal, State, local, and host nation 
regulations. 

• Disposal analyses support selection of system elements and materials that will 
be used in the system design; and they should be readdressed to consider design 
and project impacts from changing laws and regulations throughout the project 
life cycle. 

• Disposal Strategy and design considerations are updated throughout the system 
life cycle in response to changes in applicable laws, regulations, and policy 

• Consider donating an obsolete system; many items, both systems and 
information, of cultural and historical value have been lost to posterity because 
museums and conservatories were not considered as an option during the 
disposal stage. 

• Concepts such as Zero Footprint and Zero Emissions drive current trends 
toward corporate social responsibility that influence decision-making regarding 
cleaner production and operational environments and eventual disposal of 
depleted materials and systems. 11 

• The ISO 14000 series includes standards for Environmental Management 
Systems and Life Cycle Assessment. 12 

• Instead of designing cradle-to-grave products, dumped in landfills at the end 
of their 'life,' a new concept is transforming industry by creating products for 
cradle-to-cradle cycles, whose materials are perpetually circulated in closed 
loops. Maintaining materials in closed loops maximizes material value without 
damaging ecosystems. 13 


1 Used with permission, Professor Heinz Stoewer. 

2 Gilb, T., Competitive Engineering, Elsevier, 2005. 

3 Hook, I., Customer-Centered Products: Creating Successful Products Through Smart Requirements 
Management, Amacon, 2000. 

4 Martin, J. N., Systems Engineering Guidebook, CRC Press, 1996. 

5 see results of INCOSE vendor survey at www.incose.org/ProductsPubs/products/toolsdatabase.aspx 
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6 an example is Gilb’s Planguage format, see URL www.gilb.com 

7 ISO 13407: Human-centered design processes for interactive systems 

8 Gilb, T., and Dorothy Graham, Software Inspection. Addison-Wesley Longman, 1993. 

9 SysTest, Systems Verification, Validation and Testing Methodology Guidelines, Contract: G1RD-CT- 
2002-00683, http://www.incose.org/secoe/0105.htm 

10 Ibid. 

11 see URL: www.zerofootprint.net/ and www.zeri.org/ 

12 see URL: www.iso-14001.org.uk/ 

13 see URL: www.mcdonough.com/ 
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5 Project Processes 

5.1 Introduction 

Within the system life cycle, the creation or upgrade of products and Services is managed 
by the conduct of projects. For this reason, it is important to understand the contribution 
of Systems engineering to the management of the project. Systems engineers continually 
interact with project management as illustrated in Figure 5-1 below. 



Figure 5-1 Project Management/Systems Engineering Overlap' 


The processes described in this section are applied according to the risk and 
complexity of the project. These processes fail in two categories; project specific 
processes inchide project planning, project assessment, and project control; life cycle 
processes, which apply both inside and outside the project context, include decision- 
making, risk management, configuration management, and information management. 
Many of these latter processes are found throughout an enterprise as they are essential 
to generic management practices. This chapter of the handbook focuses on processes 
relevant to the technical coordination of a project. Table 5-1 contains an acronym list 
for acronyms that appear in the context diagrams in this chapter. 


Table 5-1 Acronym List 


CMP 

Configuration Management Plan 

IMP 

Information Management Plan 

QMP 

Quality Management Plan 

RMP 

Risk Management Plan 

SEP 

Systems Engineering Plan 

WBS 

Work Breakdown Structure 
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5.2 Project Planning Process 

5.2.1 Purpose 

Project planning establishes the direction and infrastructure necessary to assess and 
control the progress of a project. This process identifies the details of the work and 
the right set of personnel/skills/facilities with a schedule of need for resources from 
within and outside the enterprise. 

5.2.2 Description 

Project planning starts with a statement of need, often expressed in a project proposal. 
The planning process is performed in the context of the enterprise. Enterprise processes 
establish and identify relevant policies and procedures for managing and executing 
a technical effort; identifying the technical tasks, their interdependencies, risks and 
opportunities, and providing estimates of needed resources/budgets. This is also the 
point in the process to determine the need for resources and specialists during the project 
life-cycle to improve efficiency/effectiveness and decrease cost over-runs. For example 
during product design, various disciplines work together to evaluate parameters such as 
manufacturability, testability, operability and sustainment against product performance. 
In some cases, project tasking is concurrent to achieve the best results. Figure 5.2 is the 
Planning Process Context Diagram. 



Figure 5-2 Context Diagram for the Project Planning Process 

5.2.3 Inputs 

The primary inputs to the planning process are the project proposal and technical 
results from the initial concept exploration stage. Project resources are derived 
from and require coordination with the enterprise. The enterprise also provides the 
contextual policies, procedures and standards. 
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5.2.4 Outputs 

Principle outputs from planning are a work breakdown structure (WBS), a data 
dictionary, project milestones, task descriptions with completion criteria and work 
authorizations, a detailed budget, a project quality plan, identification of required 
technical reviews and their completion criteria, methods for controlling changes, 
risk assessment and methodology, identification of other technical plans and 
documentation to be produced for the project. 

An important outcome of planning is the Systems Engineering Plan. This plan 
identifies the activities to be accomplished, key events that must be satisfied at decision 
gates throughout the project, work packages that define the working schedule and the 
assignment of required resources (people, equipment and facilities) that define the 
project budget. Each decision gate will have a list of activities or tasks that must be 
successfully completed prior to entering the decision gate. This plan references other 
planning instruments that are tailored for use on the project such as the Configuration 
Management, Risk Management, and Information Management Plans discussed in 
later sections of this chapter. 

5.2.5 Process Activities 

Process activities include: 

• Analyze project proposal and related agreements to define project scope 

• Identify project objectives and project constraints 

• Define Key Events that provide structure for the project. Once the key events 
are established, the tasks and activities that need to be completed prior to each 
event are identified 

• Define top-level work packages for each task and activity identified. Each work 
package should be tied to resources required including procurement strategies. 
Develop project schedule based on objectives and work estimates 

• Define costs and estimate project budget 

• Prepare a Systems Engineering Plan; tailor the quality, configuration, risk and 
information management plans to meet the needs of the project. 

• Tailor the enterprise risk management processes and practices in accordance 
with the agreements and the Systems Engineering Plan to establish a systematic 
approach for identifying and handling risk. 

• Tailor the enterprise configuration management processes and practices in 
accordance with the agreements and the Systems Engineering Plan to establish 
a systematic approach for identifying and handling change requests 

• Establish tailoring of enterprise procedures and practices to carry out planned 
effort. Chapter 10 contains a detailed discussion on tailoring. 

■ Common approaches and tips: 

• Integrated product development teams are used frequently to break down 
Communications and knowledge stovepipes within organizations. 2 
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• Creation of the WBS is an activity where Systems engineering and project 
management intersect. 3 

• Skipping or taking shortcuts in the planning process reduces the effectiveness 
of other project processes. 

• Even agile project management methods include planning - the cycles may be 
shorter and more frequent, but planning is an essential process. 

• Incorporate risk assessment early in the planning process to identify areas that 
need special attention or contingencies. Always attend to the technical risks. 

• The Project Management Institute is a source of guidelines for project planning. 4 


5.3 Project Assessment Process 

5.3.1 Purpose 

This process collects and evaluates the status of the project comparing the results 
achieved against the plan to assess the maturity of the project. Assessments are 
scheduled periodically and for all milestones and decision gates. The intention is to 
maintain good Communications within the project team and with the stakeholders, 
especially when deviations are encountered. 


5.3.2 Description 

The Project Planning Process identified details of the work effort and expected 
results. Project assessment collects data to evaluate the adequacy of the project 
infrastructure, the availability of necessary resources, and compliance with project 
performance measures. A discussion of the creation and assessment of Technical 
Performance Measures (TPM) is found in chapter 7. Figure 5-3 is the context diagram 
for the Project Assessment Process. 



Figure 5-3 Context Diagram for the Project Assessment Process 
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5.3.3 Inputs 

The planning outputs provide the basis for ongoing evaluation of the progress 
and achievements of a project against performance requirements, costs, schedule, 
and overall business objectives. The enterprise provides the contextual policies, 
procedures and standards for project assessment. 

5.3.4 Outputs 

The outcome of project assessment is information on the health and maturity of the 
project work effort. Results of this process are used to make decisions regarding 
future work and technical options. 

5.3.5 Process Activities 

Activities within this process include: 

• Determine actual and projected cost against budget; actual and projected time 
against schedule and deviations in project quality 

• Evaluate the effectiveness of personnel 

• Evaluate the adequacy and the availability of the project infrastructure 

• Evaluate project progress against established criteria and milestones 

• Conduct required reviews, audits, inspections to determine readiness to proceed 
to next milestone 

• Monitor critical tasks and new technologies-see Risk Management section below 

• Make recommendations for adjustments to project plans; these are input to the 
project control process and other decision-making processes 

• Communicate status as designated in the agreements, policies and procedures 

■ Common approaches and tips: 

• One way for project management to remain updated on project status is to 
conduct regular team meetings; short standup meetings on a daily or weekly 
schedule are effective for smaller groups. 

• Prevailing wisdom suggests that “what gets measured gets done,” but projects 
should avoid the collection of metrics that are not used in decision-making and 
detract from doing real work. 

• The Project Management Institute is a source of guidelines for project assessment. 


5.4 Project Control Process 

5.4.1 Purpose 

The Project Control Process uses project assessment to direct the efforts ofthe project. 
This includes redirecting the project when deviations from the plan are uncovered, or 
the project does not reflect the anticipated maturity. 
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5.4.2 Description 

The rigor of the project control process is directly dependent on the complexity of the 
system-of-interest. Project control involves both corrective and preventive actions 
taken to ensure that the project is performing according to the plans and schedules, 
and within projected budgets. Assessments also monitor the technical progress of the 
project, and may identify new risks or areas that require additional investigation. The 
Project Control Process may trigger activities within the other process areas in this 
chapter. See Figure 5-4 for the Project Control Process Context Diagram. 



Figure 5-4 Context Diagram for the Control Process 

5.4.3 Inputs 

Results of the project assessment process are analyzed to determine the maturity of 
the project and identify any deviations from the plans or technical performance of the 
product. The project is guided by the enterprise policies, procedures, and standards. 

5.4.4 Outputs 

New directions are communicated to both project team and customer, when 
appropriate. If assessments are associated with a decision gate, a decision to proceed, 
or not to proceed, is taken. 

5.4.5 Process Activities 

The activities within this process include: 

• Analyze assessment results 

• Initiate corrective actions when the assessment indicates deviation from 
approved plan 

• Initiate preventive actions when the assessment indicates a trend toward deviation 
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• lnitiate problem resolution when the assessment indicates non-conformance 
with performance success criteria 

• Establish work items and changes to schedule to reflect the actions taken 

• Negotiate with suppliers for any goods or Services acquired from outside the 
enterprise 

• Make the decision to proceed, or not to proceed, when assessment supports a 
tollgate or milestone event 

■ Common approaches and tips: 

• Project teams need to identify critical areas and control them through 
monitoring, risk management or configuration management. 

• An effective feedback control process is an essential element to enable the 
improvement of project performance. 

• Agile project management techniques schedule frequent assessments and make 
project control adjustments on tighter feedback cycles than other plan-drive 
development models. 

• Tailoring of enterprise processes and procedures should not jeopardize any 
certifications. Processes must be established with effective review, assessment, 
audit, and upgrade as discussed in chapter 6. 


5.5 Decision-Making Process 

5.5.1 Purpose 

Decisions are made throughout the life cycle of every system whenever alternative 
courses of action exist. Milestones and decision gates mark the most formal decisions. 
Less formal decisions require less structure, bud documenting all decisions, with 
their rationale, supports future decision-making. 

5.5.2 Description 

As the system progresses from early concept definition throughout sustainment, 
decisions are needed to direct the focus of all personnel toward the desired result. 
Every decision involves an analysis of the alternative options, the selection of a course 
of action, and recording of the eventual decision with supporting documentation. 

Decisions come from many sources and range from programmatic to highly technical. 
Different strategies are appropriate to each category of decision. A more complete 
discussion of decision gates and decision-making strategies is found in chapter 7. 
All decisions are taken within the context of an enterprise. Some decisions are made 
within the context of other processes, for example approval of an engineering change 
proposal within the Configuration Management Process. See Figure 5-5 for the 
Decision-making Process Context Diagram. 
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Figure 5-5 Context Diagram for the Decision-making Process 


5.5.3 Inputs 

Decisions related to decision gates are taken on a pre-arranged schedule. Other 
requests for a decision may arise from any stakeholder. Decisions should be taken 
in consideration of prior history and all relevant persons should be involved in 
the decision-making activities. The enterprise provides the contextual policies, 
procedures and standards. 

5.5.4 Outputs 

The approved decision is documented along with rationale, assumptions, constraints 
and supporting analysis, recorded and communicated. 

5.5.5 Process Activities 

Decision-making Process activities include: 

• Identify the need for a decision and the strategy for making the decision, 
including desired outcomes and measurable success criteria 

• Identify all personnel with knowledge and experience relevant to the decision 

• Evaluate the consequences of alternative choices using the selected strategy 
and optimize the decision 

• Record the decision made with the relevant data and supporting documentation 

• Communicate new directions from the decision 

■ Common approaches and tips: 

• Decision support systems have been developed to assist decision makers in 
considering the implications of various courses of action. 

• Failure to maintain a history of prior studies and decisions can result in wasted 
effort when old questions reappear. 
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5.6 Risk and Opportunity Management Process 

5.6.1 Purpose 

Risk and opportunity management is a disciplined approach to dealing with 
uncertainty that is present throughout the entire systems life cycle. The objective 
is to achieve a proper balance between risk and opportunity. This process is used to 
understand and avoid the potential cost, schedule, and performance/technical risks 
to a system, and to take a proactive and structured approach to anticipate negative 
outcomes, respond to them if they occur; and to identify potential opportunities that 
may be hidden in the situation. Enterprises manage many forms of risk and the risk 
associated with system development is managed in a manner that is consistent with 
the enterprise strategy. 

5.6.2 Description 

Every new system or modification of an existing system is based on pursuit of 
an opportunity. Risk always is present in the life cycle of systems, and the risk 
management actions are assessed in terms of the opportunity being pursued. The 
system may be intended for technical accomplishments near the limits of the State 
of the art, creating technical risk. Risk can also be introduced during architectural 
design caused by the internal interfaces that exits between the system elements. 
System development may be rushed to deploy the system as soon as possible to 
exploit a marketing opportunity or meet an imminent threat, leading to schedule risk. 
All systems are funding-limited so that cost risk is always present. Risk can develop 
within a project, since (for example) technical risk can create schedule risk, which in 
turn can create cost risk. Chapter 7 contains a more detailed discussion of these four 
risk categories; technical, schedule, cost and programmatic. 

Ambient risk is often neglected in project management. The ambient risk is defined 
as the risk caused by and created by the surrounding environment (ambience) of the 
project 5 . Project participants have no control over ambient risk factors, but can learn 
to observe the external environment and eventually to take proactive or reactive 
action to minimize the impact of the environment on the project. The typical issues 
are time dependent processes, rigid sequence of activities, one dominant path for 
success and little slack. 

Projects are subject to uncertainty; an uncertain event may be harmful if it occurs 
(threats), another may assist in achieving objectives (opportunities). Dealing with 
both types of uncertainty under the single heading of “risk management” minimizes 
process and overhead and expands organizational and personal commitment towards 
finding and capturing opportunities. Since traditionally, project managers think 
of risks as threats alone, it may be a change to begin recognizing opportunities. If 
opportunities are handled along with threats, risk management language needs to 
be balanced with terms for opportunities such as “exploit”, “share”, “protect” and 
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“enhance”. Project managers may need encouragement to be open to opportunities 
and to manage both threats and opportunities proactively. 

Typical strategies for coping with risk include transference, avoidance, acceptance 
or taking action to reduce the anticipated negative effects of the situation. Most risk 
management processes include a prioritization scheme whereby risks with the greatest 
negative effect and the highest probability of occurrence are handled before those deemed 
to have lower negative consequences and lower probability of occurrence. The objective 
of risk management is to balance the allocation of resources such that the minimum 
amount of resources achieves the greatest risk mitigation (or opportunity realization) 
benefits. See Figure 5-6 for the Risk Management Process Context Diagram. 



Figure 5-6 Context Diagram for the Risk Management Process 


5.6.3 Inputs 

In the Project Planning Process, a Risk Management Plan is tailored to satisfy the 
individual project procedures for risk management. In many cases, risk situations 
are identified during the project assessment process. A risk management process 
establishes documentation, often maintained as a risk matrix, which includes a 
description, priority, mitigation, responsible person, and status of each risk item. 

5.6.4 Outputs 

The Risk Matrix contains the findings of the Risk Management Process. For selected 
risks, an action plan is produced to direct the project team to properly respond to the 
risks. If appropriate, change requests are generated to mitigate technical risk. 

5.6.5 Process Activities 

Process activities include: 

• Identify and define risk situations 

• Analyze risks for likelihood and severity in order to determine the magnitude 
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of the risk and its priority for handling 

• Define handling scheme and resources for each risk, including identification of 
a person who will be responsible for continuous assessment of the status of the 
situation 

• Using the criteria for acceptable and unacceptable risk, generate a plan of 
action when the risk threshold exceeds acceptable levels 

• Maintain a record of risk items and how they were handled 

• Maintain transparent risk management Communications 

■ Common approaches and tips: 

• One rule of thumb for identifying risks is to pose each risk candidate in a “if 
<situation>, then <consequence.>” format. This form helps to determine the 
validity of a risk and to assess its magnitude or importance. If the statement 
does not make sense or cannot be put in this format, then the candidate is 
probably not a true risk. For example, a statement that describes a situation but 
not a consequence implies that the potential event will not affect the project. 
Similarly, a statement of potential consequence without a clear situation 
description is worthy of more attention. 

• Document everything so if there are unforeseen issues and challenges during 
execution you can recreate the environment within which the planning decisions 
were made and know where to update the information to correct the problem. 

• Negative feedback toward personnel who identify a potential problem will 
discourage the full cooperation of engaged stakeholders, and could result in 
failure to address serious risk-laden situations. Conduct a transparent risk 
management process to encourage suppliers and other stakeholders to assist in 
the risk mitigation efforts. Some situations can be difficult to categorize vis- 
a-vis probability and consequences - involve all relevant stakeholders in this 
evaluation to capture the maximum variety in viewpoints. 

• Many analysis completed throughout the technical processes, such as FMECA, 
may identify candidate risk elements. 

• The metrics for risk management vary by organization and by project. As with 
any metric, use measurements or statistics that help manage the risk. 

• The Project Management Institute is a good source for more information on 
Risk Management. 

• The Institute of Risk Management has generated The Risk Management 
Standard. 6 

• See Forsberg, et. al. for additional reading on opportunity management . 7 


5.7 Configuration Management Process 

5.7.1 Purpose 

The objective of configuration management is to ensure effective management of 
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the evolving configuration of a system, both hardware and Software, during its life 
cycle. Fundamental to this objective is the establishment, control, and maintenance 
of Software and hardware baselines. Baselines are reference points for maintaining 
development and control. These baselines, or reference points, are established by 
review and acceptance of requirements, design, and product specification documents. 
The creation of a baseline may coincide with a project milestone or decision gate. As 
the system matures and moves through the life cycle stages the Software or hardware 
baseline is maintained under configuration control. 

5.7.2 Description 

Configuration Management ensures that product functional, performance, and 
physical characteristics are properly identified, documented, validated, and verified 
(establishing product integrity); that changes to these product characteristics are 
properly identified, reviewed, approved, documented, and implemented; and that the 
products produced against a given set of documentation are known. See chapter 8 for 
additional discussion relevant to configuration management. 

Evolving system requirements are a reality that must be addressed over the life of a 
system development effort, and throughout the Utilization and Support Stages of the 
system. See Figure 5-7 for the Configuration Management Process context diagram. 



Figure 5-7 Context Diagram for the Configuration Management Process 

5.7.3 Inputs 

In the Project Planning Process, a Configuration Management Plan is tailored to satisfy 
the individual project procedures for configuration management. In many cases, the 
need for change requests is identified during the project assessment process. 
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5.7.4 Outputs 

The primary output of the configuration management process is the maintenance of the 
configuration baseline for the system and system elements. Items are placed under formal 
control as part of the decision-making process. The required configuration baseline 
documentation is developed and approved in a timely marmer to support required 
Systems engineering technical reviews, the system’s acquisition and support strategies, 
and production. This documentation is maintained throughout the life of the system. 
The configuration management process formally documents the impact to any process, 
organizations, decisions, products, and Services affected by a given change request. 

5.7.5 Process Activities 

Process activities include: 

• Identify system elements that are maintained under configuration control 

• Maintain enough information to ensure system/product integrity 

• Establish a configuration control cycle that incorporates evaluation, approval, 
validation, and verification of engineering change requests 

• Develop and maintain configuration control documentation 

• Perform Configuration Audits associated with milestones and decision gates to 
validate the baselines 

■ Common approaches and tips: 

• Establish a configuration control board with representation from all stakeholders 
and engineering disciplines participating on the project - see chapter 8 for 
more details. 

• Begin the configuration management process in the infancy phases of the 
system and continue through until disposal of the system. 


5.8 Information Management Process 

5.8.1 Purpose 

Information Management ensures that information is properly stored, maintained, 
secured, and accessible to those who need it thereby establishing/maintaining 
integrity of relevant system life cycle artifacts. 

5.8.2 Description 

Information exists in many forms, and different types of information have different 
value within an enterprise. Information assets, whether tangible or intangible, have 
become so pervasive in contemporary organizations that they are indispensable. 
The impact of threats to secure access, confidentiality, integrity, and availability of 
information can cripple the ability to get work done. As information systems become 
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increasingly interconnected, the opportunities for compromise increase. 8 The 
following are important terms in Information Management: 

• Information is what an organization has compiled or its employees know. It 
can be stored and communicated, and it might include customer information, 
proprietary information, and/or protected (e. g. by Copyright, trademark, or 
patent) and unprotected (e. g. business intelligence) Intellectual Property. 

• Information assets are intangible information and any tangible form of its 
representation, including drawings, memos, e-mail, Computer files, and 
databases. 

• Information security generally refers to the confidentiality, integrity, and 
availability of the information assets. 

• Information security management includes the Controls used to achieve 
information security and is accomplished by implementing a suitable set 
of Controls, which could be policies, practices, procedures, organizational 
structures, and Software functions. 

• Information Security Management System is the life-cycle approach to imple- 
menting, maintaining, and improving the interrelated set of policies, Controls, 
and procedures that ensure the security of an organization's information assets 
in a manner appropriate for its strategic objectives. 

Information management provides the basis for the management of and access to 
information throughout the system life cycle, including after disposal if required. 
Designated information may include enterprise, project, agreement, technical, and 
user information. The mechanisms for maintaining historical knowledge in the 
prior processes - decision-making, risk and configuration management - are under 
the responsibility of information management. See Figure 5-8 for the Information 
Management Process Context Diagram. 



Figure 5-8 Context Diagram for the Information Management Process 
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5.8.1 Inputs 

In the Project Planning Process, an Information Management Plan is tailored to satisfy 
the individual project procedures for information management. An information 
management plan identifies the system-relevant information to be collected, retained, 
secured, and disseminated, with a schedule for retirement. 

5.8.2 Outputs 

The output of this process is the availability for use and communication of all relevant 
Systems artifacts in a timely, complete, valid and, if required, confidential manner. 

5.8.3 Process Activities 

Process activities include: 

• Establish/maintain a system data dictionary - see project planning outputs 

• Define system-relevant information, the storage requirements, access privileges 
and the duration of maintenance 

• Define formats and media for capture, retention, transmission, and retrieval of 
information 

• Identify valid sources of information and periodically obtain artifacts of 
information 

• Maintain information according to security and privacy requirements 

• Retrieve and distribute information as required 

• Archive designated information for compliance with legal, audit and knowledge 
retention requirements 

• Retire unwanted, invalid or unverifiable information according to organizational 
policy, security, and privacy requirements 

■ Common approaches and tips: 

• Identify information-rich artifacts and store them for later use even if the 
information is informal such as a design engineer’s notebook. 

• Information management delivers value to the organization and the project 
by using a variety of mechanisms to provide access to the contents of data 
repositories. Email, web-based access through intranets, and database queries 
are a few examples. 

• ISO 17799 "Code of Practice for Information Security Management" is an 
international Standard that provides a best practices framework for implementing 
security Controls. 

• ISO 10303, STandard for the Exchange of Product model data (STEP) includes 
Application Protocol (AP) 239 Product Lifecycle Support (PLCS), which 
addresses information requirements for complex systems; this topic is discussed 
in chapter 8. 9 
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6 Enterprise and Agreement Processes 

6.1 Introduction 

Enterprise processes are the purview of the organization and are used to direct, 
enable, control, and support the system life cycle. This chapter and the ISO/IEC 
15288 focus on the capabilities of an organization relevant to the realization of a 
system; they are not intended to address general business management objectives, 
although sometimes the two overlap. 

Within the enterprise, organizational units cooperate to develop, implement, deploy, 
operate, maintain and dispose of the system-of-interest. Enabling systems may also 
need to be modified to meet the needs of new systems; developed or acquired if 
they do not exist. Examples include development, manufacturing, training, testing, 
transport, maintenance and disposal systems that support the system-of-interest. 

Every enterprise claims interfaces with industry, academia, customers, partners, etc. 
An overall objective of enterprise processes is to identify these external interfaces 
and establish the parameters of these relationships, including identifying the inputs 
required from the external entities and the outputs that will be provided to them. 
This network of relationships provides the context of the business environment of the 
enterprise and access to future trends and research. Some relationships are defined by 
the exchange of products or Services. 

There are six Enterprise Processes identified by ISO/IEC 15288. They are: Enterprise 
Environment Management, Investment Management, System Life Cycle Processes 
Management, Resource Management, and Quality Management. Discussion of these 
processes and their interfaces is the topic of this chapter. The enterprise will tailor 
these processes and their interfaces to meet specific strategic and Communications 
objectives. 

There are two Agreement Processes identified by ISO/IEC 15288: the Acquisition 
Process, and the Supply Process. These processes are discussed in the closing sections 
of this chapter. They are included in this chapter because they conduct the essential 
business of the enterprise, namely the buying and selling of products and Services. 
They establish the relationships between enterprises relevant to the acquisition and 
supply of products and Services. Agreements may exist between organizational units 
internal or external to the enterprise. Figure 6-1 illustrates the critical success factors 
for enterprise and agreement processes. 1 
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Figure 6-1 Key Success Factors for Enterprise Processes 


6.2 Enterprise Environment Management Process 

6.2.1 Purpose 

The purpose of the Enterprise Environment Management Processes is to establish 
and maintain a set of policies and procedures at the enterprise level that support the 
organization’s ability to acquire and supply products and Services. 

6.2.2 Description 

The work of the organization is accomplished through projects. These projects are 
conducted within the context of the enterprise - the enterprise environment. This 
environment needs to be defined and understood within the organizations and the 
project to ensure alignment of the working units and achievement of overall enterprise 
strategic objectives. This process exists to establish, communicate, and continuously 
improve the system life cycle (SLC) process environment. Figure 6-2 contains the 
context diagram for the Enterprise Environment Management Process. 
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Figure 6-2 Enterprise Environment Management Process Context Diagram 

6.2.3 Inputs 

The network of relationships include: Government, Industry, and Academia. Each of 
these external interfaces provide unique and essential information for the enterprise 
to succeed in business and meet the continued need and demand for improved and 
effective Systems and products for the customers. It is up to the enterprise environment 
management process to fully define and utilize these external entities and interfaces, 
i. e. their value, importance and capabilities that are required by the enterprise. 

• Legislative, regulatory, and other government requirements 

• Industry systems engineering and management related standards, training, 
capability maturity models 

• Academic education, research results, future concepts and perspectives, 
requests for financial support 

The enterprise environment is built on the existing enterprise infrastructure, including 
facilities, personnel and knowledge. Integration and interoperability of supporting 
systems, such as financial, human resources, and training, is critically important to 
execute the enterprise strategic objectives. Feedback from active projects is used to 
refine and continuously improve the enterprise environment. 

6.2.4 Outputs 

The essential products from this process support the systems life cycle (SLC) 
processes in the form of policies, procedures, guidance, and directions needed for the 
enterprise to provide the most cost effective environment for a portfolio of systems 
over their life cycle. This includes: 
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• SLC strategic plans, policies, procedures, directives, guidance - for example, 
templates for management plans such as configuration, information, and risk 
management plans 

• Accountability & authority for all systems engineering & management 
processes within the enterprise 

• Roles & Responsibilities defined for systems engineering & management 
processes within the enterprise 

• Review criteria for process improvement (including assessments, approvals/ 
disapprovals, recommendations) 

6.2.5 Process Activities 

This process includes the following activities: 

• Establish Business Area plans - use the strategic objectives to identify candidate 
projects to fulfill them 

• Establish SLC policies, processes, procedures - consistent with the enterprise 
and business area plans 

• Define Roles, Responsibilities & Authorities - align the portfolio of projects 

• Define the decision-making criteria that determine entering and exiting each 
stage of the SLC - expressed in terms of business achievements 

• Conduct periodic reviews of the SLC models used by projects - use assessments 
to confirm the adequacy and effectiveness of the SLC processes 

• Disseminate policies and procedures throughout the enterprise. 

■ Common approaches and tips: 

• The process of developing the business area plans helps the enterprise to assess 
where it needs to focus activities and resources to meet present and future 
strategic objectives. Include representatives from relevant stakeholders in the 
enterprise community. 

• Manage the network of external relationships - assign personnel to identify 
standards, industry & academia research and other sources of enterprise 
management information and concepts needed by the enterprise. 

• Establish an enterprise architecture - integrating the infrastructure of the 
enterprise can make the execution of routine business activities more efficient. 

• Establish an enterprise communication plan - most of the processes in this 
handbook include dissemination activities. An effective set of communication 
methods is needed to ensure that all stakeholders are well-informed. 

• Base the policies and procedures on an Enterprise level strategic plan that 
provides a comprehensive understanding of the Enterprise’s goals, objectives, 
stakeholders, competitors, future business, and technology trends. 

• Work continually to improve the SLC processes. 
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6.3 Investment Management Process 

6.3.1 Purpose 

The purpose of the Investment Management Process is to initiate and sustain 
investments in projects that meet the objectives of the organization and to cancel or 
redirect investments for projects that do not. 

6.3.2 Description 

Projects create the products or Services that generate income for an enterprise. 
The conduct of successful projects requires an adequate allocation of funding and 
resources and the authority to deploy them to meet project objectives. Most business 
entities mange the commitment of financial resources using well defined and closely 
monitored processes. 

The Investment Management Process also performs ongoing evaluation of the 
projects in its portfolio. Based on periodic assessments, projects are determined to 
justify continued investment if they 

• are progressing toward achieving established goals; 

• are complying with project directives from the enterprise; 

• are conducted according to approved plans; and, 

• are providing a Service or product that is still needed and providing acceptable 
investment returns. 

Otherwise, projects may be redirected, or in extreme instances, cancelled. Figure 6-3 
shows the context diagram for the Investment Management Process. 



Figure 6-3 Investment Management Process Context Diagram 
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6.3.3 Inputs 

Investment opportunities are not all equal. Enterprises are limited in the number of 
projects that can be conducted concurrently. Some investments are not well aligned 
with the overall strategic plan of the enterprise. For these reasons, opportunities are 
evaluated against the portfolio of existing agreements and ongoing projects, and 
taking into consideration the attainability of the stakeholders’ requirements. 

The enterprise investment decisions are built on the existing enterprise infrastructure, 
including facilities, personnel and knowledge. Efficient use of these resources is 
achieved by exploiting opportunities to share enabling systems or to use a common 
system element on more than one project. These opportunities are enabled by good 
Communications within the enterprise infrastructure. 

6.3.4 Outputs 

The successful implementation of the Investment Management Process results in the 
following outputs: 

• Qualified investment opportunities result in the initiation of new project(s) 

• Resources and budgets are identified and allocated to the projects 

• Project management accountability and authorities are defined 

• Projects meeting assessment criteria are sustained 

• Project not meeting assessment criteria are redirected or terminated 

6.3.5 Process Activities 

This process includes the following activities: 

• Identify and assess investment opportunities consistent with the enterprise 
strategic plan. 

• Initiate projects; define project management accountabilities and authorities, 
identify expected project outcomes. 

• Allocate adequate funding and other resources. 

• Identify opportunities for multi-project synergies. 

• Specify project reporting requirements and review schedule that govern the 
progress of the project. 

• Evaluate ongoing projects to provide rationale for continuation, redirection or 
termination. 

■ Common approaches and tips: 

• When investment opportunities present themselves, prioritize them based on 
measurable criteria such that projects can be objectively evaluated against a 
threshold of acceptable performance. 

• The expected project outcomes should be based on clearly defined criteria 
that are measurable to ensure than an objective assessment of progress can be 
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determined. Specify the investment information that will be assessed for each 
milestone. Initiation should be a formal milestone that does not occur until all 
resources are in place as identified in the project plan. 

• Establish a program office or other coordination organization to manage the 
synergies between active projects in the enterprise portfolio. Complex and 
large enterprise architectures require the management and coordination of 
multiple interfaces and make additional demands on investment decisions. 
These interactions occur within and between the projects. 

• Include risk assessments in the evaluation of ongoing projects. Projects that 
contain risks that may pose a challenge in the future might require redirection. 
Cancel or suspend projects whose disadvantages or risks to the organization 
outweigh the investment. 

• Include opportunity assessments in the evaluation of ongoing projects. 
Addressing project challenges may represent a positive investment opportunity 
for the enterprise. Avoid pursuing opportunities that are inconsistent with the 
capabilities of the organization and its strategic goals and objectives or contain 
unacceptably high technical risk, resource demands, or uncertainty. 

• Allocate resources based on the requirements of the projects; otherwise, the 
risk of cost and schedule overruns may have a negative impact on quality and 
performance of the project. 

• Establish effective governance processes that directly support investment 
decision-making and Communications with project management. 


6.4 System Life Cycle Processes Management Process 

6.4.1 Purpose 

The purpose of the System Life Cycle Process Management Process is to establish a 
set of proven and effective system life cycle processes and make them available for 
use by the enterprise. 

6.4.2 Description 

This process provides integrated, system life cycle (SLC) processes necessary to 
meet the enterprise’s strategic plans, policies, goals and objectives for all projects 
and all system life cycle stages. The processes are defined, adapted and maintained to 
support the requirements of the enterprise, Systems engineering organizational units, 
individual projects and personnel. SLC processes are supplemented by recommended 
methods and tools. The resulting guidelines in the form of enterprise policies and 
procedures are still subject to tailoring by projects, as discussed in chapter 10. Figure 
6-4 is the context diagram for this process. 
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Figure 6-4 SLC Processes Management Process Context Diagram 


6.4.3 Inputs 

This handbook and relevant standards, new knowledge from research, and industry 
sponsored knowledge networks are examples of the sources from which the SLC 
processes are extracted. Enterprise strategy plans and infrastructure are used to 
ensure consistency in the eventual recommendations. Assessments from projects and 
trends collected from tailoring processes provide constructive input for improvements 
to an enterprise’s SLC implementation. 

6.4.4 Outputs 

The successful implementation of this process results in the following outputs: 

• Enterprise SLC process guidelines in the form of enterprise policies and 
procedures 

• Enterprise policies and procedures for applying the SLC processes and adapting 
them to meet the needs of individual projects 

• Performance criteria and measures that indicated the degree to which SLC 
processes are used 

• Enterprise SLC Processes Improvement Plan 

6.4.5 Process Activities 

The process activities include: 

• Identify sources (enterprise, corporate, industry, academia, stakeholders and 
customers) of SLC process information. 

• Distill the information from multiple sources into an appropriate set of SLC 
processes that are aligned with the enterprise plans and infrastructure. 

• Establish SLC Process Guideline in the form of Plans, Policies, Procedures, 
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Tailoring Guidance, Models, and Methods and Tools for controlling and 
directing the SLC processes. 

• Define, integrate, and communicate SLC process roles, responsibilities, 
authorities, requirements, measures, and performance criteria based on the 
SLC process guidelines. 

• Identify opportunities to improve the enterprise SLC guidelines on a continuing 
basis based on individual project assessments, individual feedback, and changes 
in the enterprise strategic plan. 

• Communicate with all relevant organizations regarding the creation of and 
changes in the SLC guideline. 

■ Common approaches and tips: 

• Development of an SLC Processes intranet and information database with 
essential information provides an effective mechanism for disseminating 
consistent guidelines, providing announcements about enterprise related topics 
as well as industry trends, research findings, and other relevant information. 
This provides a single point of contact for continuous communication regarding 
the SLC Guidelines and encourages the collection of valuable feedback and the 
identification of enterprise trends. 

• Establish an enterprise center of excellence for SLC Processes. This organization 
can become the focal point for the collection of relevant information, 
dissemination of guidelines, and analysis of assessments and feedback. They 
develop checklists and other templates to support project assessments to ensure 
that the pre-defined measures and criteria are used for evaluation. 

• Methods and Tools for enabling the application of SLC Processes must be 
effective and tailored to the implementation approach of the enterprise and its 
projects. Create a responsible organization to coordinate the identification and 
development of partnerships and/or relationships with tool vendors and working 
groups. They can recommend the use of methods and tools that are intended 
for the purpose to help personnel avoid confusion and frustration, and wasting 
valuable time and money. These experts may establish an integrated tool 
environment between interacting tools to avoid cumbersome (and inaccurate) 
data transfer - see chapter 8.4. 

• Including stakeholders, such as engineering and project management 
organizations, as participants in developing the SLC guidelines increases their 
commitment to the recommendations and incorporates a valuable source of 
enterprise experience. 

• Develop alternative SLC guidelines based on the type and scope, complexity, 
and risk of a project decreases the need for tailoring by engineering and project 
organizations. 

• Provide clear guidelines for tailoring and adaptation. 

• Estimating techniques for life cycle cost are described in chapter 8.5. 
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6.5 Resource Management Process 

6.5.1 Purpose 

The purpose of the Resource Management Process is to create and maintain a pool of 
resources for projects. 

6.5.2 Description 

Projects all need resources to meet their objectives. Financial resources are addressed 
under the Investment Management Process, but all other resources are provided under 
this process. Resource is a generic term for all materials, Services, facilities, and 
personnel needed by a project. Non-human resource Services include tools, databases, 
communication systems, financial systems and information technology. 

Project planners determine the resources needed by the project. They attempt to 
anticipate both current and future needs. The Resource Management Process provides 
the mechanisms whereby the enterprise infrastructure is made aware of project 
needs and the resources are scheduled to be in place when requested. While this can 
be simply stated, it is less simply executed. Conflicts must be resolved, personnel 
must be trained, employees are entitled to vacations and time away from the job, 
equipment must be purchased and sometimes repaired, buildings are refurbished, and 
information technology Services are in a State of constant change. 

The enterprise resource management organization collects the needs, negotiates to 
remove conflicts, and is responsible forproviding the enabling enterprise infrastructure 
without which nothing else can be accomplished. Since resources are not free, their 
costs are also factored into investment decisions. Figure 6-5 is the context diagram 
for the Resources Management Process. 



Figure 6-5 Resource Management Process Context Diagram 
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6.5.3 Inputs 

Resource management collects the needs of all the projects in the active portfolio. 
Personnel needs are evaluated against available people with the pre-requisite skills to 
determine if training or hiring activities are indicated. Other assets are scheduled or 
if necessary acquired. Trends in the market may suggest changes in the composition 
of project teams and the supporting IT environment. The availability and suitability 
of the enterprise infrastructure is one of the critical project assessments and provides 
feedback for improvement-and reward-mechanisms. All enterprise processes 
require mandatory compliance with government and corporate laws and regulations. 
Decision-making is governed by the enterprise strategic plan. 

6.5.4 Outputs 

The primary objective of this process is to provide a resource pool to the enterprise. 
This is complicated by the number of sources for requests, the need to balance the 
skills of the labor pool against the other infrastructure elements (e. g. computer-based 
tools), the need to maintain a balance between the budgets of individual projects 
and the cost of resources, the need to keep apprised of new or modified policies and 
procedures that might influence the skills inventory, and myriad unknowns. 

Resources are allocated based on requests and conflicts are negotiated. The goal is 
to provide personnel, materials and Services to a project when they are needed to 
keep the project on target and on budget. A key concern is keeping project personnel 
from becoming over-committed, especially persons with specialized skills. Skills 
inventory and career development plans are important documentation that can be 
validated by engineering and project management. 

6.5.5 Processes Activities 

This process includes the following activities: 

• Manage resource availability to ensure enterprise goals and objectives are 
met. Conflicts and resource shortfalls are identified with recommendations for 
resolution. 

• Provide resources to support all projects - the enterprise infrastructure. 

• Keep employees motivated, content in their career progression, current with 
their training, and appropriately allocated using techniques that are within 
acceptable enterprise and corporate guidelines and constraints. 

• Control multi-project resource management Communications to effectively 
allocate resources throughout the enterprise, identify potential future or 
existing conflict issues and problems with recommendations for resolution. 

■ Common approaches and tips: 

• Motivate staff; consider using an integrated product development team 
environment as a means to reduce the frequency of project rotation; recognize 
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progress and accomplishments and reward success; establish apprentice and 
mentoring programs for newly hired employees and students. 

• Maintain a pipeline of qualified candidates that are interested in joining the 
organization as employees or temporary staff. Focus recruitment, training and 
retention efforts on personnel with experience levels, skills and subject matter 
expertise demanded by the projects. Personnel assessments should review 
proficiency, motivation, ability to work in a team environment, as well as the 
need to be retrained, reassigned or relocated. 

• Qualified personnel and other resources may be hired temporarily/leased - 
insourced or outsourced - in accordance with the investment strategy. 

• Encourage personnel to engage in external networks as a means of keeping 
abreast of new ideas and attracting new talent to the organization. 

• Maintain an enterprise career development program that is not sidetracked 
by project demands. Develop a policy that all personnel receive training or 
educational benefits on a regular cycle. This includes both undergraduate and 
graduate studies, in-house training courses, certifications, tutorials, workshops, 
and conferences. 

• Remember to provide training on enterprise policies and procedures and SLC 
processes. 

• Establish a resource management information infrastructure with enabling 
support systems and Services to maintain, track, allocate and improve the 
resources for present and future enterprise needs. Computer-based human 
resource, equipment tracking, facilities allocation and other systems are 
recommended for organizations over 50 people. 

• Attend to physical factors, including facilities and human factors, such as 
ambient noise level and Computer access to specific tools and applications. 

• Begin planning in early life cycle stages for utilization and support resource 
requirements for system transition; manpower, facilities, infrastructure, 
information/data storage and management. 

• Use the slack time in the beginning of a project to obtain and train the necessary 
people to avoid a shortfall of skilled engineers, technologists, managers, and 
operations experts. 


6.6 Quality Management Process 

6.6.1 Purpose 

The purpose of the Quality Management Process is to make visible the goals of the 
enterprise toward customer satisfaction. Enterprise policies and procedures govern 
the products, Services, and implementations of the system life cycle (SLC) processes 
to assure that they meet quality objectives and customer requirements. 
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6.6.2 Description 

Since primary drivers in any project are time, cost, and quality, inclusion of a Quality 
Management Process is essential to every organization. Many of the SLC processes 
are concerned with quality issues, and this forms some of the justification for exerting 
time, money, and energy into establishing these processes in the organization. 
Application of this handbook is one approach toward inserting a quality discipline 
into an organization. 

The Quality Management Process establishes, implements, and continuously 
improves the focus on customer satisfaction and enterprise goals and objectives. 
There is a cost to managing quality as well as a benefit. The effort and time required 
to manage quality should not exceed the overall value gained from the process. 
Chapter 8 contains additional discussion of the importance to the organization, and 
activities for implementing this process. Figure 6-6 is the context diagram for the 
Quality Management Process. 



Figure 6-6 Quality Management Process Context Diagram 


6.6.3 Inputs 

Enterprise strategic documentation including quality policy, mission, strategies, 
goals and objectives are essential inputs for analysis and synthesis of quality impacts, 
requirements and Solutions. Existing agreements also provide direction regarding the 
appropriate level of attention given to quality within the organization. 

Project assessments include measurements that can be evaluated to determine the 
performance of a project team and the progress toward a quality outcome. Trends 
in tailoring of project-specific quality plans provide clear indications of potential 
improvements in the overall enterprise guidelines. 
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The team of people working in this process will also find a wealth of material in ISO 

standards and other sources. 

6.6.4 Outputs 

The successful implementation of the Quality Management Process results in the 

following outcomes: 

• Enterprise Quality Management Guidelines include the set of policies and 
procedures that apply to quality practices within the organization, within 
individual projects, and as part of the execution of SLC processes. These 
guidelines define goals and quality objectives for processes and Systems that 
are measurable and objective. 

• Accountability and authority for quality management is assigned within the 
organization and realistic resources are provided. 

• Customer satisfaction is closely monitored and appropriate actions are taken 
when quality goals are not achieved. 

6.6.5 Process Activities 

This process includes the following activities: 

• Establish Quality Management Guidelines - Policies, Standards, and 
Procedures 

• Establish enterprise and project quality management goals & objectives 

• Define Responsibilities & Authorities 

• Monitor Customer Satisfaction against compliance with requirements and 
objectives 

• Evaluate project assessments and recommend appropriate action when 
indicated 

• Continuously improve the Quality Management Guidelines 

• Maintain open Communications within the organization 

■ Common approaches and tips: 

• Management commitment to quality is reflected in the strategic planning of the 
enterprise - the rest of the organization will follow. Everyone in the Enterprise 
should know the Enterprise’s quality policy. 

• Quality is a daily focus - not an afterthought! 

• Development of a Quality Management intranet and information database 
with essential information provides an effective mechanism for disseminating 
consistent guidelines, providing announcements about enterprise related topics 
as well as industry trends, research findings, and other relevant information. 
This provides a single point of contact for continuous communication regarding 
the Quality Management Guidelines and encourages the collection of valuable 
feedback and the identification of enterprise trends. 

• Analyze statistics from process audits, tests and evaluations, product 
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discrepancy reports, customer satisfaction monitoring, accident and incident 
reporting, and the implementation of changes to items of a product (e.g. recalled 
product and/or production lines). 

• Quality Management is big business. A plethora of standards, methods, and 
techniques exist to help an organization. A short list includes the ISO 9000 
series, Total Quality Management (TQM), and Six-Sigma (statistical process 
control). Quality according to ISO 9000 is the “Ability of a set of inherent 
characteristics of a product, system, or process to fulfill requirements of 
customers and other interested parties.” 2 

• A successful strategy is to aim at achieving customer satisfaction primarily 
by preventing non-fulfillment of requirements. Ideally, customer satisfaction 
is linked to compliance with requirements - two signals that the process is 
not working are situations where the project is compliant but the customer is 
unhappy, or the project is not compliant and the customer is happy. 

• The consistent involvement and commitment of top management with timely 
decision-making is mandatory for the quality program. This is reflected in 
staffing and training of project auditors. 


6.7 Acquisition Process 

6.7.1 Purpose 

The Acquisition Process is invoked to establish an agreement between two enterprises 
under which one party acquires products or Services from the other. The acquirer 
experiences a need for an operational system, for Services in support of an operational 
system, for elements of a system being developed by a project, or for Services in 
support of project activities. The goal is to find a supplier that can meet that need. 

6.7.2 Description 

The role of the acquirer demands familiarity with the Enterprise, Project, and 
Technical Processes as it is through them that the supplier will execute the agreement. 
An acquirer enterprise applies due diligence in the selection of a supplier to avoid 
costly failures and impacts to the enterprise budgets and schedules. This section is 
written from the perspective of the acquirer enterprise. Figure 6-7-1 is the context 
diagram for the Acquisition Process. 
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Figure 6-7 Acquisition Process Context Diagram 


6.7.3 Inputs 

The Acquisition Process begins with the identification of a need that can not be met 
within the organization encountering the need, or a need that can be met in a more 
economical way by a supplier. The organization identifies candidate suppliers that 
could meet this need, and the acquisition personnel identify a plan for procuring 
the system-of-interest. During creation of a request for proposal, inputs are received 
from the project management and engineering personnel in the organization with the 
need. These same personnel participate in the evaluation of the responses and offer 
recommendations for the selection of supplier. The selection criteria documented in 
the acquisition plan are used to drive this decision. 

Legally executed agreements must comply with government and other directives. 
The acquirer enterprise will adopt Standard practices related to the negotiation of 
agreements. It is important to note that availability of adequate funding is essential to 
beginning the acquisition process. 

6.7.4 Outputs 

The following are outcomes of the Acquisition Process. 

• Acquisition Plan-include objective selection criteria and a schedule of 
milestones 

• List potential suppliers -suppliers may be internal or external to the acquirer 
enterprise 

• Recommendations from evaluation of responses to request for proposal 
- formal documentation, or less formal inter-organizational interactions, e.g. 
between design engineering and marketing 
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• Supplier selected - using selection criteria; rank suppliers by their suitability 
to meet the overall need; establish supplier preferences and corresponding 
justifications 

• Negotiated agreement - formal contracts, or less formal inter-organizational 
work orders 

• System-of-interest (product or Service) delivered according to delivery condi- 
tions of agreement 

• Acquirer payments or other compensations rendered 

• Responsibility for system-of-interest transferred from supplier to acquirer 

• Communication between acquirer and supplier 

• Acquisition strategies regarding agreements 

6.7.5 Process Activities 

The following activities take place under the Acquisition Process: 

• Manage Acquisition Process activities -decision-making for agreements, 
relationship building and maintenance, interaction with Enterprise management, 
responsibility for the development of plans and schedules, final approval 
authority for deliveries accepted from supplier. When an acquisition process 
cycle concludes, conduct a final review of performance to extract lessons- 
learned for continued process performance. 

• Develop and maintain Acquisition Plans, Strategies, Policies, Procedures to 
meet the enterprise goals and obj ectives and the needs of the proj ect management 
and technical systems engineering organizations. 

• Select appropriate suppliers - willing to conduct ethical negotiations, able 
to meet technical obligations, willing to maintain open Communications 
throughout the acquisition process. 

• Evaluate supplier responses to request for proposal - system-of-interest meets 
acquirer needs and complies with industry and other standards. Assessments 
from the Investment and Quality Management Processes, and recommendations 
from the requesting organization are necessary to determine the suitability of 
each response and the ability of the supplier to meet the stated commitments. 

• Select the preferred supplier based on acquisition criteria. 

• Negotiate agreement - acquirer commits to specify requirements for system-of- 
interest, participate in verification, validation and acceptance activities, render 
payment according to the schedule, participate in exception and change control 
procedures, and contribute to transparent risk management procedures. The 
agreement will establish criteria for assessing progress toward final delivery. 

• Maintain Communications with supplier, stakeholders, and other organizations 
regarding the project. 

• Assess execution of agreements to identify risks and issues, progress towards 
mitigation of risks, adequacy of progress toward delivery, evaluation cost 
and schedule performance, and determine potential undesirable outcomes 
for the enterprise. Amend agreements when impacts on schedule, budget, or 
performance are identified. 
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• Accept delivery in accordance with all agreements and relevant laws and 
regulations. 

• Render payment or other agreed consideration in accordance with agreed 
payment schedules. 

• Accept responsibility in accordance with all agreements and relevant laws and 
regulations. 

■ Common approaches and tips: 

• Establish acquisition guidance and procedures that inform acquisition 
planning, including recommended milestones, standards, assessment criteria 
and decision gates. Include approaches for identifying, evaluating, choosing, 
negotiating, managing and terminating suppliers. 

• Establish a point of responsibility within the enterprise for monitoring and 
controlling individual agreements. This person maintains communication with 
the supplier, and is part of the decision-making team to assess progress in the 
execution of the agreement. The possibility of late delivery or cost overruns 
should be identified and communicated into the enterprise as early as noted. 

• Define and track metrics that measure the progress on agreements. Appropriate 
metrics requires the development of tailored metrics/measures that do not drive 
unnecessary and costly efforts but do provide the information needed to assure 
the progress is satisfactory and key issues and problems are identified early to 
allow time for resolution with minimal impact to the delivery and quality of the 
product and Service. 

• Include technical representation in the selection of the suppliers to critically 
assess the capability of the supplier to perform the required task; this helps 
reduce the risk of contract failure and its associated costs, delivery delays, and 
increased resource commitment needs. Past performance is highly important 
but changes to key personnel should be identified and evaluated. 

• Communicate clearly with the supplier about the real needs; avoid conflicting 
statements, or making frequent changes in the statement of need that introduce 
risk into the process. 

• Maintain traceability between the supplier’s responses to the acquirer’s 
solicitation; this can reduce the risk of contract modifications, cancellations or 
follow-on contracts to fix the product or Service. 


6.8 Supply Process 

6.8.1 Purpose 

The Supply Process is invoked to establish an agreement between two enterprises 
under which one party supplies products or Services to the other. Within the 
supplier enterprise, a project is conducted according to the recommendations of this 
handbook with the objective to provide a product or Service that meets the contracted 
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requirements. In the case of a mass produced product or Service, a marketing function 
may represent the acquirer and establish customer expectations. 

6.8.2 Description 

The supply process is highly dependent upon the Enterprise, Project, and Technical 
Processes as it is through them that the work of executing the agreement is accomplished. 
This means that the supply process is the larger context in which the other processes 
are applied under contract. This section is written from the perspective of the supplier 
enterprise. Figure 6-8 is the context diagram for the Supply Process. 



Figure 6-8 Supply Process Context Diagram 


6.8.3 Inputs 

The products and Services available for acquisition are determined within the enterprise 
strategic plan. Legally executed agreements must comply with government and other 
directives. A supplier connects with another party with the desire to acquire their 
products or Services. The supplier enterprise will adopt Standard practices related to 
the negotiation of agreements. During the evaluation of the request from the acquirer, 
inputs are received from project management and engineering organizations, 
including potential sub-suppliers. 

6.8.4 Outputs 

The following are outcomes of the Supply Process. 

• Identification of potential acquirers 

• Response to acquirer request for proposal - formal documentation, or less 
formal inter-organizational interactions, e. g. between design engineering and 
marketing 
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• Negotiated agreement - formal contracts, or less formal inter-organizational 
work orders 

• System-of-interest (product or Service) delivered according to delivery 
conditions of agreement 

• Acquirer payments or other compensations received and acknowledged 

• Responsibility for system-of-interest transferred between acquirer and 
supplier 

• Communication between acquirer and supplier 

• Supplier strategies regarding agreements 

6.8.5 Process Activities 

The following activities take place under the Supply Process: 

• Manage Supply Process activities -decision-making for agreements, relationship 
building andmaintenance, interaction with Enterprise management, responsibility 
for the development of plans and schedules, final approval authority for deliveries 
made to acquirer. When a supply process cycle concludes, conduct a final review 
of performance to extract lessons-learned for continued process performance. 

• Develop and maintain Supply Plans, Strategies, Policies, Procedures to meet 
the enterprise goals and objectives and the needs of the project management 
and technical systems engineering organizations. 

• Select appropriate acquirers - willing to conduct ethical negotiations, able 
to meet financial obligations, willing to maintain open Communications 
throughout the supply process. 

• Evaluate acquirer requests and prepare a response - a satisfactory response 
proposes a system-of-interest that meets acquirer needs and complies with 
industry and other standards. Assessments from the Investment, Resource 
Management, and Quality Management Processes are necessary to determine 
the suitability of this response and the ability of the enterprise to meet these 
commitments. 

• Negotiate agreement - supplier commits to meet requirements for system- 
of-interest, meet delivery milestones, verification, validation and acceptance 
conditions, accept payment schedule, execute exception and change control 
procedures, and maintain transparent risk management procedures. The 
agreement will establish criteria for assessing progress toward final delivery. 

• Execute the agreement - start a project and invoke the other processes defined 
in this handbook. 

• Maintain Communications with acquirer, sub-suppliers, stakeholders, and other 
organizations regarding the project. 

• Assess execution of agreements to identify risks and issues, progress towards 
mitigation of risks, adequacy of progress toward delivery, evaluation cost and 
schedule performance, and determine potential undesirable outcomes for the 
enterprise. 
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• Deliver in accordance with all agreements and relevant laws and regulations. 

• Receive and acknowledge payment or other agreed consideration in accordance 
with agreed payment schedules. 

• Transfer responsibility in accordance with all agreements and relevant laws 
and regulations. 

■ Common approaches and tips: 

• Agreements fail into a large range from formal to very informal based on 
verbal understanding. Contracts may call for a fixed price, cost plus fixed fee, 
incentives for early delivery, penalties for late deliveries, and other financial 
motivators. 

• Relationship building and trust between the parties is a non-quantifiable quality 
that, while not a substitute for good processes, makes the human interactions 
agreeable. 

• Develop technology white papers or similar documents to demonstrate and 
describe to the (potential) acquirer the range of capabilities in areas of interest. 
Use traditional marketing approaches to encourage acquisition of mass 
produced products. 

• Maintain an up-to-date internet presence, even if the enterprise does not engage 
in electronic commerce. 

• When expertise is not available within the enterprise (e. g. legal and other 
governmental regulations, laws, etc.), retain subject matter experts to provide 
information and specify requirements related to agreements. 

• Invest sufficient time and effort into understanding acquirer needs before 
the agreement. This can improve the estimations for cost and schedule and 
positively affect agreement execution. Evaluate any technical specifications for 
the product or Service for clarity, completeness and consistency. 

• Involve personnel who will be responsible for agreement execution to participate 
in the evaluation of and response to the acquirer’s request. This reduces the 
start-up time once the project is initiated, which in turn is one way to recapture 
the cost of writing the response. 

• Make a critical assessment of the ability of the organization to execute the 
agreement; otherwise, the high risk of failure and its associated costs, delivery 
delays, and increased resource commitment needs will reflect negatively on the 
reputation of the entire enterprise. 

• lnstitute for supply management has useful guidance for purchasing and 
marketing . 3 


1 ©2001 Jack Ring and A. Wayne Wymore 

2 http://www.iso.ch/iso/en/iso9000-14000 

3 http://www.napm.org/ 
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7 Enabling Systems Engineering Process 
Activities 

Systems Engineering Process Activities are covered in three chapters: 

• Chapter 7 - Enabling Systems Engineering Activities 

• Chapter 8 - Systems Engineering Support Activities 

• Chapter 9 - Specialty Engineering Activities 

Chapter 1 (Table 1-1) provides summary guidance to the process activities covered in 
these chapters for those who may not be familiar with all of them. 

From a sampling of the literature 1 in Systems Engineering from 1962 to the present, 
a common set of process activities emerges. This is the same set as that identified 
by a joint project between The American Institute of Aeronautics and Astronautics 
(AIAA) and INCOSE in which they are referred to as “enabling 2 ” processes. The 
enabling processes are Decision Management, Requirements Management, and Risk 
and Opportunity Management. When tailoring a project, most of these activities will 
be essential to every system life cycle. 

7.1. Decision Management 

This section on Decision Management gives a glimpse into decision gates, making 
difficult decisions, and trade studies. 

7.1.1. Decision Gates 

A decision gate is an approval event in the project cycle, sufficiently important to be 
defined and included in the schedule by the project manager, executive management, 
or the customer. Entry and exit criteria are established for each gate at the time they 
are included into the project management baseline. Decision gates ensure that new 
activities are not pursued until the previously scheduled activities, on which new ones 
depend, are satisfactorily completed. Proceeding beyond the Decision Gate before 
the project is ready entails risk, as comically illustrated in Figure 7-1. The project 
manager may decide to accept that risk, as is done, for instance, with long-lead item 
procurement. 
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Figure 7-1 Decision Gates synchronize project aetivities 3 


The project business case issues of market demand, affordability, and realistic 
sehedules are important decision eriteria influencing concept selection, and they 
should be updated and evaluated at every decision gate. Inadequate checks along 
the way can set up subsequent failures - usually a major faetor in cost over-runs and 
delays. At each gate the decision options are: 

Acceptable: Proceed with the next stage of the project; 

Or Acceptable with reservations : Proceed and respond to aetion items; 

Unacceptable: Do not proceed; continue this stage and repeat the review when 

ready; 

Unacceptable: Return to a preceding stage; 

Unacceptable: Put a hold on project activity; 

Unsalvageable: Terminate the project. 

Upon successful completion of a decision gate, some artifaets (documents, models, or 
other produets of a project eyele stage) have been approved as the basis upon which 
future work must build. If the project is large or long enough, or entails high risk, 
these artifaets are placed under configuration management. 


Decision gate deseriptions should identify the: 

• Purpose of the decision gate 

• Host and chairperson 

• Attendees 

• Location 

• Agenda and how the decision gate is to be conducted 

• Evidence to be evaluated 

• Actions 

• Method of elosing the review 

Decision gate approval must involve the necessary disciplines and stakeholders and 
must be based on hard evidence of compliance. One of the underlying principles 
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for the agile development and extreme programming movements is to substantially 
reduce (but not eliminate) the frequency and elaborate (and they would claim pro- 
forma) content of decision gates for Software development. Balancing the formality 
and frequency of decision gates is seen as a critical success factor for all systems 
engineering process areas. On large or lengthy projects, decisions and their rationale 
are maintained using an information management process. 

7.1.2 Making Difficult Decisions 

Making good decisions requires adequate information, experience, and good 
judgment. The techniques discussed in the following paragraphs are found in the 
literature, and have proven to be effective aids in making good decisions. In some 
cases, a technique may use mathematics to produce a result useful in the decision- 
making process, such as the hydrographical models used to assess the environmental 
restrictions in the 0resund Strait. People make decisions based on intuition and 
judgment; these techniques are aides to decision-making. 4 

Decision analysis is a method of identifying the best option from a set of alternatives, 
under uncertainty, using the possible outcomes of each alternative and their 
probabilities of occurrence to calculate the expected value of the outcome. Decision 
analysis has been a subject of interest for centuries, 5,6,7 and can be applied to a wide- 
range of problems and problem domains. 

Skinner 8 States, “Real world decisions often involve a high degree of ambiguity, 
conflicting goals due to multiple objectives, complex trade-offs, more than one 
decision maker, or several sequential decisions. It is these types of situations where 
decision analysis is most valuable. By carefully decomposing the problem into 
smaller more manageable problems and by focusing on what is truly important, we 
can develop clear objectives and defensible courses of action.” 

Skinner also lists ten principles of good decision making: 

1. Use a value creation lens for developing and evaluating opportunities. 

2. Clearly establish objectives and trade-offs. 

3. Discover and frame the real problem. 

4. Understand the business situation. 

5. Develop Creative and unique alternatives. 

6. Identify experts and gather meaningful and reliable information. 

7. Embrace uncertainty as the catalyst of future performance. 

8. Avoid “analysis paralysis” situations. 

9. Use systemic thinking to connect current to future situations. 

10. Use dialog to foster learning and clarity of action. 


Page 7.3 of 20 

Copyright ©2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. 


INCOSE-TP-2003-002-03 
June 2006 


INCOSE Systems Engineering Handbook v. 3 


Advocates of Lean Manufacturing would add one more suggestion to this list; delay 
commitment until the last responsible moment. Lean Software development delays 
freezing all design decisions as long as possible, because it is easier to change a 
decision that is not made. 9 

Decision trees are a graphical and quantitative method for thinking through a decision. 
The first step is to create a decision “tree” diagram that represents the situation in 
question. Starting on the left with the initial decision point and proceeding to the 
right, the decision diagram must accurately represent each point where a decision is 
to be made and all the possible consequences of that decision. Figure 7-2 illustrates a 
situation where management needs to decide on whether or not to bid on a contract. 
The team estimates that their company has a 60% chance of winning. If they propose 
a unit price of $30, the company will earn $4.25 M, where M is 106. They further 
estimate that there is a 10% chance that the unit cost will be $28, which would result 
in an increase in income to $6 M. There is a 40% chance that the unit cost could be as 
high as $38, and the project will lose about $3 M. The unit costs and probabilities of 
each chance outcome are based on the best judgment of the team. 

The expected value of winning the contract is the sum of the expected value for each 
branch at the chance node times the probability for each branch. So 

Contract Win Expected Value = 10% * $6.05 M + 50% * $4.25 M - 40% * $2.95M 
or $1.55M 

The expected value of making the bid is 60% * $1.55 - 40% * 0.25 or $0.83 M 



This technique can be extended to include multiple decision points and multiple 
outcomes as long as every possible outcome has a value and a probability of occurrence 
associated with it. 
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Additional decision analysis techniques include: 

a. Sensitivity analysis, which looks at the relationships between the outcomes 
and their probabilities to find how “sensitive” a decision point is to the relative 
numerical values. 

b. Value of information methods, whereby expending some effort on data analysis 
and modeling can improve the optimum expected value. 

c. Multi-attribute Utility Analysis, which is a method that develops equivalencies 
between dissimilar units of measure. 

There are many tools available to support the decision management area. The INCOSE 
website maintains suggestions from the Tools Working Group. 

7.1.3 Trade Study and Sensitivity Analysis 

Trade study describes a process for comparing the appropriateness of different 
technical Solutions. The characteristics of each option are traded against each other. 
Once a best alternative has been identified, the stakeholders in the decision will want 
to know how sensitive the recommended selection is to differently evaluated criteria 
or to different estimates of the alternatives’ characteristics — perhaps a different best 
alternative would result. Therefore, a good trade study includes sensitivity analysis. 

A recent study reported that the following activities can be found in most trade study 
processes: 11 

1. Frame the problem context, scope, constraints. 

2. Establish Communications with stakeholders. 

3. Define evaluation criteria and weights where appropriate. 

4. Define alternatives and select candidates for study. 

5. Define measures of merit and evaluate selected candidates. 

6. Analyse the results and select best alternative. 

7. Review results with stakeholders and re-evaluate. 

8. Investigate the consequences of implementation. 

9. Use scenario planning to test assumptions about the future. 

The utility or value of each feature of an alternative is determined or estimated, and 
often a weight is defined that assigns a relative importance of each feature across 
all alternatives. The weighted value of utility is simply the product of the utility 
and the weight for each feature, and the weighted total is the sum of the weighted 
utility values summed over all the features of an alternative. The selected alternative 
nominally is the one with the best weighted total. Involvement of the stakeholders in 
this process gives them confidence in the eventual choice and imparts useful insights 
to the whole team. 
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A sensitivity analysis involves varying each utility and each weight and re-computing 
the weighted total for each alternative to ascertain what would change if the values of 
the Utilities or weights were different. The significance ofthe change is best determined 
through conversations with stakeholders and subject matter experts. All evaluations 
and decisions are reviewed to address the concerns and opinions of stakeholders. 

A final evaluation of the consequences of implementing the selected alternative may 
help identify unintended consequences of an otherwise “best” solution. The highest 
score does not always win. 

Trade studies support decisions in all phases of system development, from 
conceptualization to deployment. Requirements can be traded against constraints; 
architecture features can be traded against dictated equipment or interface 
requirements; alternative functional or performance choices can be traded to 
determine an optimal configuration. In the case of the 0resund Bridge, trade studies 
helped determine many of the final elements of the bridge configuration, e. g. length 
of main span. 


7.2 Requirements Management 

There is near unanimous agreement that successful projects depend on meeting the 
needs and requirements of the stakeholder/customer. When the requirements are for 
a complex system, or for a system that may take many years to realize, a formal 
requirements management process is justified. Requirements management concerns 
the collection, analysis, and validation of requirements with all the Communications 
and negotiations inherent in working with people. 

A great deal of literature exists on how to write and manage requirements. This 
overview touches on four major elements of this process area; elicit and capture 
requirements, generate a concept of operations, define system capabilities and 
performance objectives, and define non-functional requirements. 

7.2.1 Elicit and Capture Requirements 

Within the context of ISO/IEC 15288, requirements are specifically mentioned in 
two of the technical processes, and are drivers for many of the system life cycle 
processes. Depending on the system development model, requirements capture may 
be done nominally once near the beginning of the development cycle, or as for agile 
methods, be a continuous activity. The reason for eliciting requirements is the same, 
understand the needs of the stakeholders well enough to support the architecture 
design process. 
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One of the biggest challenges in this activity is the Identification of the set of 
stakeholders from whom requirements should be elicited. Customers and eventual 
end-users are relatively easy to identify, but regulatory agencies, and other interested 
parties that may reap the consequences of the system-of-interest should also be sought 
out and heard. In sustainable development this includes finding representation for 
future generations. Figure 7-3 illustrates the range of potential stakeholders. 


Users 



Figure 7-3 Requirements elicitation captures the needs of stakeholders, 
operators and users across Systems boundaries 12 

Requirements elicitation is an iterative activity and benefits from continuous 
communication and validation with stakeholders. Techniques for requirements 
elicitation include interviews, focus groups, the Delphi technique, and soft systems 
methodology. Tools for capturing and managing requirements are many and varied. 
The INCOSE Tools Database Working Group evaluates the relative merits of different 
products and maintains a database that is available from the INCOSE website. 

7.2.2 Systems Modeling Language (SysML) 

SysML is used to model complex systems and is an extension of the family of UML- 
based standards that are intended to provide Standard representations with well 
defined semantics that can support model and data interchange. SysML has been 
developed as part of a joint initiative between the Obiect Management Group and 
INCOSE. 13 - 14 - 15 


SysML includes diagrams that can be used to specify system requirements, behaviour, 
structure, and parametric relationships. The modelling elements represented in the 
diagram facilitate integration among the various diagrams and views. The SysML 
diagram types in Figure 7-4 are summarized below. 
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SysML Diagram 
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Figure 7-4 SysML Diagram Types 

The system structure is represented as block definition diagrams and internal block 
diagrams. A block definition diagram describes the system hierarchy and system/ 
component classifications. The internal block diagram describes the internal structure 
of a system in terms of its parts, ports, and connectors. 

The behavior diagrams include the use case diagram, activity diagram, sequence 
diagram, State machine diagram, and timing diagram. A use-case diagram provides 
a high-level description of the system functionality. The activity diagram represents 
the flow of data and control between activities. A sequence diagram represents the 
interaction between collaborating parts of a system. The State machine diagram 
describes the State transitions and actions that a system or its parts perform in 
response to events. The timing diagram represents parameters, functions or States as 
a function of time. 

The requirements diagram captures requirements hierarchies, and the derivation, 
satisfaction, and verification relationships. It provides a bridge between requirements 
and system design models. The parametric diagram represents constraints on 
system parameter values such as performance, reliability, and mass properties to 
support engineering analysis. SysML includes an allocation relationship to represent 
allocation of functions to components, allocation of logical to physical components, 
and other types of allocations. 

7.2.3 Concept of Operations 

Scenarios and what-if thinking are essential tools for planners who rnust cope with 
the uncertainty of the future. Scenario thinking can be traced back to the writings of 
early philosophers such as Plato and Seneca . 16 As a strategic planning tool, scenario 
techniques have been employed by military strategists throughout history. Building 
scenarios serves as a methodology for planning and decision-making in complex 
and uncertain environments. The exercise makes people think in a Creative way, 
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observations emerge which reduce the chances of overlooking important factors, 
and the act of creating the scenarios enhances Communications within and between 
organizations. 

Creation or upgrade of a system shares the same uncertainty regarding future use and 
emergent properties of the system. The Stakeholder Requirements Definition Process 
suggests capturing the understanding of stakeholder needs in a series of concept 
documents, each focused on a life cycle stage, see chapter 4.2. The goal of a concept 
document is to capture an implementation-free understanding of stakeholders’ needs 
by defining what is needed, without addressing how to satisfy the need. It captures 
behavioral characteristics required of the system in the context of other systems with 
which it interfaces, and captures the manner in which people will interact with the 
system for which the system must provide capabilities. 

If the system is for a military customer, there may be several required operational views 
of the system driven by architectural frameworks. These are defined, for example, in 
the United States Department of Defense Architecture Framework (DODAF) and in 
the Ministry of Defense (UK) Architecture Framework (MODAF). 

One objective is to ensure that operational needs are clearly understood and the 
rationale for performance requirements is incorporated into the design decision 
database. Other objectives are: 

a. To provide traceability between operational needs and the captured source 
requirements. 

b. To establish a basis for requirements to support the system over its life, such as 
personnel requirements, support requirements, etc. 

c. To establish a basis for test planning, system-level test requirements, and any 
requirements for environmental simulators. 

d. To generate operational analysis models to test the validity of external interfaces 
between the system and its environment, including interactions with external 
systems. 

e. To provide the basis for computation of system capacity, behavior under/ 
overload, and mission-effectiveness calculations. 

f. To validate requirements at all levels and to discover implicit requirements 
overlooked from other sources. 

Since a concept of operations describes system behavior, a starting point for building 
up the concept is to begin by identifying outputs generated by external systems 
(modified as appropriate by passing through the natural system environment) 
which act as stimuli to the system-of-interest, causing it to take specified actions 
and produce outputs, which in turn are absorbed by external systems. These single 
threads of behavior eventually cover every aspect of operational performance, 
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including logistical modes of operation, operation under designated conditions, and 
behavior required when experiencing mutual interference with multi-object systems. 
Aggregation of these single threads of behavior represents a dynamic statement of 
what the system is required to do. 

Scenario building is an essentially human activity that may involve interviews with 
operators of current/similar systems, potential end users, and meetings of an Interface 
Working Group. The results of this exercise can be captured in many graphical forms 
using modeling tools and simulations. 

7.2.4 Define systems capabilities and performance objectives 

The concepts of production, deployment, operations, and support serve as an excellent 
foundation from which the systems engineer can discern the required capabilities of 
the system-of-interest and the relevant performance objectives of the system. Together 
with identified system constraints, these will drive the architecture design activities. 

Typical constraints on the system may include: 

• Cost and schedule 

• Mandated use of Commercial Off-The-Shelf (COTS) equipment 

• Operational environment and use of pre-existing facilities and system 
elements 

• Operational interfaces with other systems or organizations 

As a result of this activity, a number of performance requirements will be identified. 
These may include areas such as power, propulsion, Communications, data processing, 
environmental, and human interaction and intervention. In the Maglev Train, the 
desire to cover large distances in a brief time established train speed parameters, 
and the need to carry people suggested safety and maximum noise tolerances. It is 
advisable to place the assumptions, constraints, and analyses associated with derived 
requirements in the decision and/or requirements database(s). 

The concept of operations will also help identify adverse consequences of derived 
requirements: 

• Is unnecessary risk being introduced? 

• Is the technology producible? 

• Are sufficient resources available to move forward? 

• Are trade studies needed to determine appropriate ranges of performance? 

Large systems may justify the development of a high-level system simulation evolved 
from the system architecture. The simulation should contain sufficient functional 
elements that the interactions can be properly assessed. The purpose of the simulation 
is to establish measurable parameters for the functional requirements. This provides 
the necessary guidance to the designers on the size and capability required of their 
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equipment. In addition, these parameters will be used as an integral part of the 
verification process in establishing the capability of the equipment (and the system) 
to satisfy user needs. 

When time permits, use of an interdisciplinary team to audit the requirements may 
help ensure the clarity, completeness and consistency of the set. Such a team can 
also assess that the requirements are verifiable. Unfortunately, it is possible to write 
reasonable-sounding requirements which in fact cannot be met. In the 1980s, a 
government/industry team created requirements for a weather satellite program, with 
eight satellites to be built and launched, one every three years. The specifications 
were - and still are - so tight that the last satellite scheduled to be launched in 2008 
must have a waiver, since it cannot meet the original specifications. 

If there is uncertainty associated with a requirement, it should be identified as 
needing further attention, and even proposed for monitoring as part of the project risk 
management. Resolution of uncertainty should be assigned as a responsibility to an 
individual, and progress and eventual resolution recorded in the decision database. 

7.2.5 Technical Performance Measures 

Technical Performance Measures (TPM) express the objective performance 
requirements, are evaluated at decision gate reviews, and may be used to assess the 
risk position of the project. TPM provide visibility into important project technical 
parameter status to enable effective management enhancing the likelihood of 
achieving the technical objectives of the project. Limit the number of TPM being 
monitored to critical issues. Collecting too many measures without knowing how 
they can be used wastes time and resources, and, even worse, the really useful values 
may become lost in the ocean of data. 

Without TPM, a project manager could fail into the trap of relying on cost and schedule 
status alone, with perhaps the verbal assurances of technical staff to assess project 
progress. This can lead to a product developed on schedule and within cost that does 
not meet all key requirements. Values are established to provide limits that give early 
indications if a TPM is out of tolerance, as illustrated in Figure 7-5. 
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Figure 7-5 TPM Monitoring 


Periodic recording of the status of each TPM provides the continuing verification of 
the degree of anticipated and actual achievement of technical parameters. Measured 
values that fail outside an established tolerance band will alert management to take 
corrective action. 


7.2.6 Define other non-functional requirements 

The concept documents will also suggest requirements that are not directly related to 
the primary capability provided by the system-of-interest. Many of these are discussed 
further in chapter 9.2, such as availability, supportability, security, and training. The 
0resund Bridge case illustrated the avoidance of negative environmental impact by 
establishing constraints on the construction practices. Addressing non-functional 
requirements from the earliest stages is a good way to ensure that they are not 
forgotten and that they are satisfied. 

7.3 Risk and Opportunity Management 

Most projects are executed in an environment of uncertainty. Uncertainty influences 
the ability of the project team to achieve the project objectives. Uncertainty includes 
events that could harm the project (threats) and those that could help the project 
(opportunities). Well-established techniques exist for managing threats. There is some 
debate whether the same techniques are applicable to recognizing opportunities. In 
an optimal situation, opportunities are maximised at the same time as threats are 
minimised, resulting in the best chance to meet project objectives. 17 The 0resund 
Bridge case illustrates this; the man-made Peberholm Island was created from the 
materials dredged from the Strait to meet environmental requirements and is now a 
sanctuary for a rare species of tern. 
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7.3.1 Concepts 

Definitions: Risks are events that if they occur can jeopardize the successful 
completion of the project. Risks should be identified and assessed for probability of 
occurrence and impact on the project. 18 

“Traditionally, risk has been defined as the likelihood of an event occurring coupled 
with a negative consequence of the event occurring. In other words, a risk is a potential 
problem — something to be avoided if possible, or its likelihood and/or consequences 
reduced if not.” 19 As a corollary, opportunity is “the potential for the realization of 
wanted, positive consequences of an event.” 20 

Fundamentals: the measurement of risk has two components as illustrated in Figure 7-6: 

• The likelihood that an event will occur. 

• The undesirable consequence of the event if it does occur. 



Figure 7-6 Level of risk depends upon both likelihood and consequences 

The likelihood that an undesirable event will occur often is expressed as a probability. 
The consequence of the event is expressed in terms that depend on the nature of 
the event (e. g. lost investment, inadequate performance). The combination of low 
likelihood and low undesirable consequences gives low risk, while high risk is 
produced by high likelihood and highly undesirable consequences. 

By changing the adjective from undesirable to desirable the noun changes from risk 
to opportunity, but the diagram remains the same. As suggested by the shading, most 
projects experience a comparatively small number of high risk or high opportunity 
events. 
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Risk pervades the life cycle of Systems. The system may be intended for technical 
accomplishments near the limits of the State of the art, creating technical risk. System 
development may be rushed to deploy the system as soon as possible to meet an 
imminent threat, leading to schedule risk. Ali systems are funding-limited so that 
cost risk is present. Risk can be introduced by external constraints or can develop 
from within the project, since technical risk can create schedule risk, which in turn 
can create cost risk. 

There is no alternative to the presence of risk in system development. The only way 
to remove risk is to set technical goals very low, to stretch the schedule, and to supply 
unlimited funds. None of these events happen in the real world. No realistic project 
can be planned without risk. The challenge is to define the system and the project 
which best meet overall requirements, which allow for risk, and which achieve the 
highest chances of project success. 

Figure 7-7 illustrates the major interactions between the four risk categories; 
technical, cost, schedule and programmatic. The arrow names indicate typical risk 
relationships; others certainly are possibe. 



Figure 7-7 Typical Relationship among the Risk Categories 

Technical risk is the possibility that a technical requirement of the system may not be 
achieved in the system life cycle. Technical risk exists if the system may fail to achieve 
performance requirements; to meet operability, producibility, testability, integration 
requirements; or to meet environmental protection requirements. A potential failure 
to meet any requirement which can be expressed in technical terms is a source of 
technical risk. 

Cost risk is the possibility that available budget will be exceeded. Cost risk exists if the 
project must devote more resources than planned to achieve technical requirements; 
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if the project must add resources to support slipped schedules due to any reason; if 
changes must be made to the number of items to be produced; or, if changes occur in 
the enterprise or national economy. Cost risk can be predicted at the total project level 
or for a system element. The collective effects of element-level cost risks can produce 
cost risk for the total project. 

Schedule risk is the possibility that the project will fail to meet scheduled milestones. 
Schedule risk exists if there is inadequate allowance for acquisition delays. 
Schedule risk exists if difficulty is experienced in achieving scheduled technical 
accomplishments, such as the development of Software. Schedule risk can be incurred 
at the total project level for milestones such as deployment of the first system element. 
The cascading effects of element-level schedule risks can produce schedule risk for 
the total project. 

Programmatic risk is produced by events which are beyond the control of the project 
manager. These events often are produced by decisions made by personnel at higher 
levels of authority. Programmatic risks can be produced by reductions in project 
priority, by delays in receiving authorization to proceed with a project, by reduced or 
delayed funding, by changes in enterprise or national objectives, etc. Programmatic 
risk can be a source of risk in any of the other three risk categories. 

The Risk Management process activities are Risk Identification, Risk Assessment, 
Risk Handling, Risk Tracking and Control, and Risk Mitigation. 

7.3.2 Risk Identification 

The purpose of risk identification is to identify risks and evaluate their relative severity. 
The basis for this evaluation may be qualitative or quantitative. Ali stakeholders 
and project personnel should feel welcome to contribute to risk identification. The 
objective is to set priorities and focus attention on areas of risk with the greatest 
consequences to the success of the project. 

If a project is unprecedented, brainstorming using SWOT (Strength-Weakness- 
Opportunity-Threat) or Delphi techniques may be appropriate. But most projects 
represent a new combination of existing systems or system elements or represent the 
insertion of incremental advances in technology. This means that key insights can 
be gained concerning a current project’s risk by examining the successes, failures, 
problems, and Solutions of similar prior projects. The experience and knowledge 
gained, or lessons learned, can be applied to identify potential risk in a new project 
and to develop a strategy for risk management. 

The first step is to determine the information needs in this phase of risk management. 
This could vary from assessing the risk in development of a custom Computer chip to 
identifying the risks associated with a major system development. The second step 
is to define the basic characteristics of the new system. This is necessary to identify 
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past projects that are similar in technology, function, design, etc. Then, based on the 
availability of data, analogous Systems or subsystems are selected and data gathered. 
Often the data collection process and initial assessment lead to a further definition of 
the system for the purposes of comparison. After this has been accomplished, the last 
step in the process is the analysis and normalization of the historic data. Comparisons 
to prior systems may not be exact or the data may need to be adjusted to be used as a 
basis for estimating the future. The desired output is insight into cost, schedule, and 
technical risks of a project based on observations of similar past projects. 

7.3.3 Risk Assessment 

Uncertainty is characterized by a distribution of outcomes based on likelihood of 
occurrence and severity of consequences. Risk involves both the probability and 
consequences of the possible outcomes. In its most general form, risk assessment 
should capture the spectrum of outcomes relative to the desired project technical 
performance, cost, and schedule requirements. Risk generally needs to be assessed 
subjectively because adequate statistical data are rarely available. 

Expert Interviews: Efficient acquisition of expert judgments is extremely important 
to the overall accuracy of the risk management effort. The expert interview technique 
consists of identifying the appropriate experts, questioning them about the risks in 
their area of expertise, and quantifying these subjective judgments. One result is the 
formulation of a range of uncertainty or a probability density function (with respect 
to cost, schedule, or performance) for use in any of several risk analysis tools. 

Since expert interviews result in a collection of subjective judgments, the only real 
“error” can be in the methodology for collecting the data. If it can be shown that the 
techniques for collecting the data are not adequate, then the entire risk assessment 
can become questionable. For this reason, the methodology used to collect the 
data must be thoroughly documented and defensible. Experience and skill are 
required to encourage the expert to divulge information in the right format. Typical 
problems encountered include identification of the wrong expert, obtaining poor 
quality information, unwillingness of the expert to share information, changing 
opinions, getting biased viewpoints, obtaining only one perspective, and conflicting 
judgements. When conducted properly, the expert interviews provide very reliable 
qualitative information. However, the transformation of that qualitative information 
into quantitative distributions or other measures depends on the skill of the analyst. 

Models: Risk is often expressed only in qualitative terms or by a single value. 
However, it is very important to quantify risk in some methodical way to assure a 
good allocation of resources for risk reduction. Ideally, risk would be characterized 
by using cumulative probability curves with the probability of failure and the 
consequences expressed quantitatively in measurable terms, but given the inherent 
lack of data and limited analysis, this is usually impractical. It is very important 
to properly quantify risk because an invalid assessment could lead to an improper 
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conclusion with misapplication of resources. 

Expected Value Model: A somewhat subjective, relative rating of risk is developed, 
where risk is expressed as: 

Expected consequence = Probability of failure (Pf )* Consequences of failure (C f). 

For illustration purposes, consider a proposal to develop a new light-weight and 
compact power supply with an operating life of 8,000 hours. The consequences of 
failing to meet at least 6,000 hours are assessed to be critical, so the consequence 
of failure is assigned a value of 0.8. Given the present State of technology, cost and 
schedule, the probability of failing to achieve an operating life of 6,000 hours is 
judged to be relatively low and is estimated as 30% (0.3). 

Applying the equation to the above example yields 

Risk = 0.3*0.8 = 0.24 

This would suggest a relatively low risk situation. Intuitively, the described scenario 
represents a low/moderate risk (subjective judgment); therefore this approach appears 
to yield a valid relative ranking of risk. 

7.3.4 Risk Handling 

Risk handling approaches need to be established for the moderate and high-risk items 
identified in the risk assessment effort. These activities are formalized in the Risk 
Management Project Plan, produced within the Risk Management Process, chapter 
5.6. There are basically four (4) approaches to handle risk: 

• accept the risk and do no more; 

• mitigate the risk by expending budget and other resources to reduce likelihood 
and/or severity; 

• transfer the risk by agreement with other party that it is in their scope to 
mitigate; or, 

• deal with a risk that has occurred. 

7.3.5 Risk Tracking and Control 

Project management uses metrics to simplify and illuminate the risk management 
process. Each risk category has certain indicators, which may be used to monitor 
project status for signs of risk. Tracking the progress of key system technical 
parameters can be used as an indicator of technical risk. 

The typical format in tracking technical performance is a graph of a planned value 
of a key parameter plotted against calendar time. A second contour showing actual 
value achieved is included in the same graph. Cost and schedule risk are monitored 
using the products of the Cost/Schedule Control System or some equivalent technique. 
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Normally cost and schedule variances are used, along with a comparison of tasks 
planned to tasks accomplished. 

7.3.6 Risk Mitigation 

Risk mitigation activities conform to the risk handling options. There are some steps 
that can be taken to avoid unnecessary risks. 

Reguirements scrubbing - Requirements that significantly complicate the system 
can be scrutinized to ensure that they deliver value equivalent to their investment. 
Find alternative Solutions that deliver the same or comparable capability. 

Selection of most promising options - In most situations several options are 
available, and a trade study can include project risk as a criterion when selecting the 
most promising alternative. 

Staffing and team building - Projects accomplish work through people. Attention to 
training, teamwork, and employee morale can help avoid risks introduced by human 
errors. 

For high-risk technical tasks, risk avoidance is insufficient and can be supplemented 
by the following approaches: 

• Early procurement 

• Initiation of parallel developments 

• Implementation of extensive analysis and testing 

• Contingency planning 

The high-risk technical tasks generally imply high schedule and cost risks. Cost and 
schedule are impacted adversely if technical difficulties arise and the tasks are not 
achieved as planned. Schedule risk is controlled by early procurement of long-lead 
items and provisions for parallel-path developments. However, these activities also 
result in increased early costs. Testing and analysis can provide useful data in support 
of key decision points. Finally, contingency planning involves weighing alternative 
risk mitigation options. 

In China, the authorities built the short Maglev train line in Shanghai as a proof-of- 
concept. In spite of the high investment, this represented lower risk to the project than 
attempting a longer line with an unproven technology. This results collected from this 
project are inspiring others to consider Maglev alternatives for greater distances. 

A number of references exist on the topic of risk management. 2 1,22, 23, 24, 25 
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8 Systems Engineering Support Activities 

The topics in chapter 8 are covered in alphabetical order by topic title to avoid giving 
more weight to one topic over another. See Table 1-1 for an overview. The objective of 
this chapter is to present the most frequently recommended set of activities within the 
Systems engineering effort. Depending on the nature of the project, its complexity, 
size, and duration, some or most of these activities will be included in the project 
execution. More information about each activity can be found in references to external 
sources and the IPAL. 

8.1 Acquisition and Supply 

The initiation of a project begins with user need. Once a need is perceived and 
resources are committed to establish a project it is possible to define the parameters 
of an acquisition and supply relationship. This relationship exists whenever an 
organization with a need does not have the ability to satisfy that need without 
assistance. Acquisition is also an alternative for optimising investment when a 
supplier can meet the need in a more economical or timely manner. The Acquisition 
and Supply Processes are the subject of chapters 6.7 and 6.8, respectively. 

The acquisition and supply processes are two sides of the same coin. Each process 
establishes the contractual context and constraints under which the other system life 
cycle processes are performed. The unique activities for the agreement processes are 
related to contracts and managing business relationships. An important contribution of 
the ISO/IEC 15288 is the recognition that systems engineers are relevant contributors 
in this domain. 1 The Maglev train case is an example where the government 
representatives of China and Germany participated in the relationship. 

Contract negotiations are handled in various ways depending on the specific 
organization. In a process that is widely used, the contracts organization in industry 
(or the contracting officer in the government) is responsible for negotiating contracts, 
including the contract terms and conditions. Key parameters such as profit target and 
acceptable contract type (firm fixed price, cost plus fixed fee, cost plus award fee) are 
established by the business area manager or by enterprise management. 

Project managers rarely lead contract negotiations, however, the lead contract 
negotiator should only agree to any changes in scope, cost, or schedule with the 
project manager’s approval. The systems engineer is in a supporting role to the project 
manager during negotiations. 

The lead contract negotiator may need, within minutes or a few hours, an assessment 
of the impact of customer-proposed changes; for major changes, the team may 
need a few days. In preparation for contract negotiations, systems engineers often 
perform preliminary trade studies on a range of cost, schedule, and technical 
performance options that might be proposed by the customer during negotiations 
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(or, for subcontract negotiations, changes that might be presented by the supplier). Of 
particular importance is the impact to project risk. What is needed is accuracy - not 
precision - so the team is prepared for anything reasonable that might arise. A team 
that is prepared will always have a more favorable outcome in negotiations, and the 
buyer will be pleased to work with a knowledgeable provider. 

A critical element to each party is the definition of acceptance criteria. These criteria 
protect both sides of the business relationship - the acquirer from being coerced into 
accepting a product with poor quality; and the supplier, from the vagaries of a fickle 
or indecisive buyer. 

8.2 Architectural Design 

Developing the system architecture is one of the most important responsibilities 
of the systems engineer. It is a Creative process, and there is no unique solution to 
satisfying user requirements. The system architecture is critical because it provides 
the framework for system development. The Architectural Design Process is the topic 
of chapter 4.4. 

In his book Wasson States, “System, product, or Service architectures depict the 
summation of a system’s entities and capabilities levels of abstraction that support 
all phases of deployment, operations, and support.” 2 In 1987 John Zachman first 
formally enunciated the opinion that in the modern world we should no longer talk 
about multiple architectures; that instead we need to talk about multiple views of a 
single broad-reaching architecture. 3,4 Consider developing architectural alternatives 
that are significantly different in their approach to meeting stakeholder requirements, 
as illustrated in Figure 8-1. 


Alternative Architecture Concept Example 
for Intercontinental Telephone Communication 



Figure 8-1 Example of Alternative Architectural Concepts 
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Creating an effective system architecture draws on the experience, intuition, and 
good judgment of the team to devise an appropriate solution. As Rechtin and Maier 
define it, systems architecting builds on four methodologies: 5 

• Normative (solution based) such as building codes and communication 
standards. 

• Rational (method based) such as systems analysis and engineering. 

• Participative (stakeholder based) such as concurrent engineering and 
brainstorming. 

• Heuristic (lessons learned) such as “Simplify. Simplify. Simplify.” 

Because systems architecting is a Creative process, and because intuition and 
experience play such an important role, the systems engineer must pay attention to 
situations where past experience and intuition have been a handicap. The book, The 
Innovator's Dilemma, 6 by Clayton Christensen, clearly sets forth the benefit of making 
Creative use of past experience. He uses the example of the Computer hard disk drive 
industry in which experience had been a key factor to the growth of companies that 
dominated the hard disk market. Christensen then highlights the transition difficulties 
for companies making large disks and their inability to capture any market share when 
the industry moved to smaller size disks. According to Christensen no manufacturer 
made a successful transition from a 14-inch (35.6 cm) disk to the 8-inch (20.3 cm) 
disk; a whole new set of companies dominated that market. This was repeated as 
the sizes dropped from 8 to 5-14 to 3-14 to 2-14 to 1.8 inches. This sequence started 
in 1980s and is continuing today with the flash drives. ln each of these transitions, 
the established companies lost out, in part because their established user base was 
locked-in to the older architecture, and in part, because their entire enterprise from 
systems engineering to marketing to manufacturing to executive management was 
unable to see the new vision. 

8.2.1 Interoperability Analysis 

Interoperability depends on the compatibility of components of a large and complex 
system (which may sometimes be called a system of systems or a family of systems) 
to work as a single entity. This feature is increasingly important as the size and 
complexity of systems continues to grow. Pushed by an inexorable trend toward 
electronic digital systems and pulled by the accelerating pace of digital technology 
invention, commercial firms and national enterprises span the world in increasing 
numbers. As their spans increases, these commercial and national enterprises want 
to make sure that their sunk investment in legacy components of the envisioned new 
system is protected and that new components added over time will work seamlessly 
with the legacy components to comprise a unified system. 

Standards have also grown in number and complexity over time, yet compliance with 
standards remains one of the keys to interoperability. The standards that correspond 
to the layers of the ISO-OSI Reference Model for peer-to-peer communication 
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Systems once fit on a single wali chart of modest size. Today it is no longer feasible 
to identify the number of standards that apply to the global Communications network 
on a wali chart of any size. lnteroperability will increase in importance as the world 
grows smaller due to expanding Communications networks, and as nations continue 
to perceive the need to communicate seamlessly across international coalitions of 
commercial enterprises or national defense forces. 

The 0resund Bridge demonstrates the interoperability challenges faced when just 
two nations collaborate on a project; meshing of regulations on health and safety, and 
the resolution of two power supply Systems for the railway. 

8.2.2 Manufacturing and Producibility Analysis 

The capability to produce a system element is as essential as the ability to properly 
define and design it. If a designed product can not be manufactured, this causes 
design rework and program delays with concomitant cost overruns. For this reason, 
production engineering analysis and trade studies for each design alternative form 
an integral part of the Architectural Design process. One objective is to determine if 
existing proven processes are satisfactory since this could be the lowest risk and most 
cost-effective approach. The Maglev train contractor experienced a steep learning 
curve to produce an unprecedented system from scientific theory. 

Critical producibility requirements are identified during system analysis and design 
and included in the program risk analysis, if necessary. Long-lead-time items, 
material limitations, special processes, and manufacturing constraints are evaluated. 
When production engineering requirements create a constraint on the design, they 
are communicated and documented. 

Producibility analysis is a key task in developing low cost, quality products. 
Multidisciplinary teams work to simplify the design and stabilize the manufacturing 
process to reduce risk, manufacturing cost, lead time, and cycle time; and to minimize 
strategic or critical materials use. Design simplification considers ready assembly and 
disassembly for ease of maintenance and preservation of material for recycling. The 
selection of manufacturing methods and processes are included in early decisions. 

Manufacturing analyses draw upon the Concept of Production, Concept of 
Deployment, and Concept of Maintenance. Manufacturing test considerations are 
shared with the engineering team and are taken into account in Built-In-Test and 
Automated Test Equipment. 

IKEA is often used as an example of supply chain excellence. 1KEA has orchestrated a 
value creating chain that begins with motivating customers to perform the final phases 
of furniture assembly in exchange for lower prices and a fun shopping experience. They 
achieve this through designs that support low cost production and transportability - the 
bookcase that comes in a flat package and goes home on the roof of a car. 
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8.3 Configuration Management 

The purpose of Configuration Management (CM) is to establish and maintain control 
of requirements, documentation, and artifacts produced throughout the system’s life 
cycle. The Configuration Management Process is the topic of chapter 5.7. 

Change is inevitable, as indicated in Figure 8-2, and managing the impact of 
change on a project is the work of CM. Systems engineers ensure that the change is 
necessary, and that the most cost-effective recommendation has been proposed. It is 
important also to ask: “What is the impact of not making the change?” especially as 
the system matures, since changes made later in the life cycle have an increasing risk 
of hidden impacts which can adversely affect system cost, schedule, and technical 
performance. 





Required 
l for 
' Final 
Delivery 


J 


Figure 8-2 Requirements changes are inevitable 


CM is the practice of applying technical and administrative direction, surveillance, 
and Services to: 

• Identify and document the characteristics of system elements such that they are 
unique and accessible in some form; assign a unique identifier to each version 
of each system element; 

• Establish Controls to allow changes in those characteristics; ensure consistent 
product versions; 

• Record, track, and report status pertaining to change requests or problems with 
a product; maintain comprehensive traceability of all transactions. 


The initial planning efforts for CM are defined in the Configuration Management 
Plan that establishes the scope of items that are covered by the plan, the resources and 
personnel skill level required, defines the tasks to be performed, identifies CM tools 
and processes, as well as methodology, standards and procedures that will be used 
on the project. Configuration control maintains integrity by facilitating approved 
changes and preventing the incorporation of unapproved changes into the items 
under configuration control. Such activities as check-in and check-out of source code, 
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versions of system elements, and deviations of manufactured items, are part of the 
CM. Independent configuration audits assess the evolution of a product to ensure 
compliance to specifications, policies, and contractual agreements. Formal audits 
may be performed in support of decision gate review. 

A request to change the current configuration of a system is typically made using 
an engineering change proposal (ECP). An ECP may originate in a number of ways. 
The customer may request an ECP to address a change in requirements or a change 
in scope; an unexpected breakthrough in technology may result in the supplier of a 
system element proposing an ECP; or a supplier may identify a need for changes in 
the system under development, and an ECP may originate to address those changes. 
Circumstances like these that will potentially change the scope or the requirements 
are appropriate reasons to propose an ECP and to conduct an analysis to understand 
the effect of the change on existing plans, costs, and schedules. The ECP must be 
approved before the change is put into effect. lt is never appropriate to propose an 
ECP to correct cost or schedule variances absent of change in scope. A minor change 
that falls within the current project scope usually does not require an ECP but should 
be approved and result in the generation of an engineering notice (EN). 

The most desirable outcomes of an ECP cycle are (1) that system functionality is 
altered to meet a changing requirement; or (2) that new technology or a new product 
extends the capabilities of the system beyond those initially required in ways that the 
customer desires, (3) that the costs of development, or of utilization, or of support 
are reduced; or (4) that the reliability and availability of the system are improved. 
Outcomes (3) and (4) reduce life cycle costs, and potentially save more money than is 
invested to fund the proposed change. 

Evolving system requirements are a reality that must be addressed over the life of 
a system development effort, and throughout the utilization and support stages of 
the system. ECPs and ENs help ensure that a system evolves in ways that allow it 
to continue to satisfy its operational requirements and its objectives and that any 
modification is known to all relevant personnel. The camera system illustrated in 
Figure 2-2 is an example of a product family that depends on accurate identification of 
system elements and characteristics to support the mix & match consumer market. 

8.4 Information Management 

The purpose of Information Management (IM) is to maintain an archive of information 
produced throughout the system’s life cycle. The Information Management Process 
is the topic of chapter 5.8. 

The initial planning efforts for IM are defined in the Information Management Plan 
that establishes the scope of project information that is maintained, the resources and 
personnel skill level required, defines the tasks to be performed, identifies IM tools 
and processes, as well as methodology, standards and procedures that will be used 
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on the project. Typical information includes source documents from stakeholders, 
contracts, project planning documents, test documentation, engineering analysis 
reports, and the files maintained by CM. Today IM is most often concerned with the 
integration of databases such as the decision database - with results from decision 
gate reviews and other decisions taken on the project; requirements management tools 
databases; computer-based training and electronic interactive user manuals; websites 
and share information spaces accessed over the internet, such as (for example) INCOSE 
CONNECT. The Standard for the exchange of product model data (STEP - ISO 10303) 
will provide a neutral computer-interpretable representation of product data throughout 
the life cycle. ISO 10303-239 (Product Life Cycle Support) is an international Standard 
that specifies an information model that defines what information can be exchanged and 
represented to support a product through life. 7 INCOSE is a co-sponsor of ISO 10303- 
233 (AP233) - Systems Engineering Data Exchange. Figure 8-3 shows how AP233 
would be used to exchange data between a SysML and other Systems Engineering 
application and then to applications in the larger life cycle of Systems potentially using 
related ISO STEP data exchange capabilities. 


Example SE Structures Exchange 
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Figure 8-3 AP233 facilitates data exchange 


With effective IM, information is readily accessible to authorized project and 
enterprise personnel. Challenges related to maintaining databases, security of data, 
sharing data across multiple platforms and organizations, and transitioning when 
technology is updated are all handled by IM. With all the emphasis on knowledge 
management, organizational learning and information as competitive advantage, 
these activities are gaining increased attention. 

8.5 Investment Management 

The purpose of Investment Management is to balance the use of financial assets within 
the enterprise. The Investment Management Process is the topic of chapter 6.3. 

8.5.1 Define the Business Case 

Enterprise management generally demands that there will be some beneficial return 
for the effort expended in pursuing a project. The business case establishes the 
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scope of required resources (people and money) and schedule, and sets reasonable 
expectations. An important element of each design gate is a realistic review of 
the business case as the project matures. The result is re-verification or perhaps 
restatement of the business case. The Iridium case described in chapter 3.2 illustrates 
the dangers of failing to keep a realistic perspective. Despite the technological 
triumph of implementing the world’s first Maglev train line, the exorbitant initial 
cost and the slow return on investment are causing the authorities to question plans 
to build another line. 

The business case may be validated in a variety of ways. For large projects, creation 
of a sophisticated engineering model, or even prototypes of key system elements, 
help prove that the objectives of the business case can be met, and that the system 
will work as envisioned prior to committing large amounts of resources to full-scale 
engineering and manufacturing development. For very complex systems, such a 
demonstration can be conducted at perhaps twenty percent of development cost. For 
smaller projects, when the total investment is modest, proof-of-concept models may 
be constructed during the Concept Stage to prove the validity of the business case 
assumptions. 

8.5.2 Cost-Effectiveness Analysis 

In economics, the term cost-effectiveness applies to the comparison of the relative 
spending (costs) and outcomes (effects) associated with two or more courses of action. 
System cost-effectiveness analysis is helpful for deriving critical system performance 
and design requirements, and supports decision-making. Some examples of critical 
cost/effectiveness analyses are: 

1. Studies of the desirable performance characteristics of commercial aircraft to 
increase an airline’s market share at lowest overall cost over its route structure 
(more passengers, better fuel consumption) 

2. Studies of the desired characteristics of a Communications satellite to serve 
specified markets most economically (placement, coverage) 

3. Urban studies of the most cost/effective improvements to a city’s transportation 
infrastructure (buses, trains, motorways, and mass transit routes and departure 
schedules). 

Military and government acquisitions are under the scrutiny of auditing offices to 
demonstrate that the money spent has delivered the expected benefits.8 A recent 
concept, Cost as an Independent Variable builds on cost-effectiveness studies to 
determine an objective cost for the system acquisition. Once the cost is agreed, it 
becomes a constraint on future decisions regarding project execution. 9 
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8.5.3 Life Cycle Cost Analysis 

As discussed in chapter 2, decisions made during the early stages of a project inevitably 
have an impact on future expenditures. New systems are designed, developed, 
manufactured, and tested over the span of many years, as in the case of a new automobile, 
or nearly two decades in the case of a submarine. Over such lengths of time, decisions 
made at the outset may have substantial, long-term effects that are frequently difficult 
to analyze. 

Life cycle cost (LCC) analysis is a method of economic evaluation which takes into 
account all relevant costs of a system over a given period of time adjusting for differences 
in the timing of those costs. 10 For products purchased off the shelf, the major factors 
are the cost of acquisition, operation, maintenance, and disposal. Otherwise, it may be 
necessary to include the costs associated with each of the six life cycle stages. A life 
cycle cost analysis results in a timetable of expenses so that an organization can cover 
its costs. If all costs can not be covered, it may not be possible to produce the system. 

In some literature, LCC is equated to total-cost-of-ownership. LCC analysis helps the 
project manager understand the total cost impact of a decision; to compare between 
decision alternatives; and to support trade studies for decisions made throughout the 
system life cycle. 

LCC normally includes the following costs, represented in Figure 8-4. Accuracy in 
the estimates will improve as the system evolves and the data used in the calculation 
is less uncertain. 


1. Research and Development costs 

2. Investment (Production/Deployment/Installation) costs 

3. Utilization and Support costs 

4. Disposal costs 



Figure 8-4 Life Cycle Cost Elements (not to scale) 
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Examples of the justification for LCC analysis 

A typical example of a decision with a long-term effect concerns the choice of 
system elements and parts for a new system. Often, the desire to minimize the initial 
investment by selecting less expensive parts carries the consequence of a higher 
probability of failures during the operational life of the system and the corresponding 
higher maintenance costs. 

Therac-25 is an example where the decision to save time and money on Software unit 
testing resulted in undetected design errors that emerged later during operation. 

A third example relates to the need for logistics support. Maintenance costs during 
the operational stage can be reduced by including in the system built-in test equipment 
that identifies problems, locates their source, and recommends a corrective course of 
action. Diagnostic testing elements of this type that combine sensors with automated 
checklists and expert systems logic are expensive to develop, but in the long run 
decrease maintenance costs and increase availability. A relatively small change in 
mean-time-to-repair or mean-time-between-failures can result in large cost savings 
during the Operations Stage. 

Advantages of LCC analysis 

LCC analysis has three important benefits - Ali costs associated with a system 
become visible: upstream; locked in costs, such as R&D; downstream; customer 
service.il - Supports an analysis of enterprise interrelationships. Reinforces the 
importance of locked in costs, such as R&D; low R&D expenditures may lead to 
high customer Service costs in the future. - Project managers can develop accurate 
revenue predictions. 

Methods / Techniques 

1. Wide-band Delphi techniques - estimations from multiple technical and 
domain experts (estimations only as good as the experts) 

2. Analogy - estimating by comparing the proposed project with one or more 
completed projects that are judged to be similar, with corrections added for 
known differences (for early estimations) 

3. Price-To-Win - focuses on providing an estimate, and associated solution, at or 
below the price judged necessary to win the contract. 

4. Algorithmic (parametric) - uses mathematical algorithms to produce cost 
estimates as a function of cost driver variables, based on historical data; often 
supported by commercial tools/models. 

5. Design-To-Cost or Cost-As-An-Independent-Variable - based on a design 
solution that stays within a predetermined set of resources. 
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8.6 Project Planning 

The purpose of Project Planning is to estimate the budget and schedule for a project 
against which to monitor the progress. This process is the topic of chapter 5.2. As 
illustrated in Figure 5-1, Systems engineers and project managers collaborate in 
project planning. 

Systems Engineers perform technical management activities consistent with project 
objectives. Technical management activities include planning, scheduling, reviewing, 
and auditing the Systems Engineering process as defined in the Systems Engineering 
Plan (SEP), and the Systems Engineering Master Schedule (SEMS). 

The SEP is the top-level plan for managing the Systems Engineering effort. The 
SEP defines how the project will be organized, structured, and conducted and how 
the total engineering process will be controlled to provide a system that meets 
stakeholder requirements. A well-written SEP provides guidance to a project and 
helps the organization avoid unnecessary discussions about how to perform Systems 
Engineering. Enterprises generally maintain a template of the SEP suitable for 
tailoring and reuse. Project-specific appendices are often used to capture detailed and 
dynamic information such as a schedule of milestones and decision gate reviews, and 
the methodology to be used in resolving problems uncovered in reviews. Effective 
project control requires that there be a SEP which the Systems engineer keeps current 
and uses on a daily basis to manage the team’s actions. 

The SEMS is an essential part of the SEP and a tool for project control. It identifies 
the critical path of technical activities in the project. Verification activities may 
also receive special attention in the SEMS. In addition, the schedule of tasks and 
dependencies helps justify requests for personnel and resources needed throughout 
the development lifecycle. 

The SEP and SEMS are supported by a Work Breakdown Structure (WBS) that defines 
a project task hierarchy. A description of the enterprise procedures for starting work on 
a part of the WBS may be defined in the SEP. Under some circumstances, the SEP may 
address Design to Cost and Value Engineering practices to provide insight into system/ 
cost effectiveness. For example, “Can the project be engineered to have significantly 
more value with minimal additional cost?” If so, does the customer have the resources 
for even the modest cost increase for the improvement? The intent is to assure the 
customer that no obvious cost effective alternatives have been overlooked. 

8.7 Quality Management 

The purpose of Quality Management is to outline the policies and procedures 
necessary to improve and control the various processes within the enterprise that 
ultimately lead to improved business performance. The Investment Management 
Process is the topic of chapter 6.3. 
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8.7.1 Process Compliance Reviews 

Enterprises that set internal policies and procedures conduct periodic process 
compliance reviews to assess the effectiveness or their processes. Such reviews are 
conducted on a recurring basis and may be combined with other assessments (such 
as ISO 9000), to reduce the perceived burden. The review should address defects in 
the examined process at the time of the review, the improvement process, tailoring 
of the process, and tailoring of the improvement process (if applicable). Enterprise 
management prioritizes and approves changes based on requested or recommended 
areas for improvement in the Standard processes. Sometime, it is sufficient to provide 
additional tailoring guidelines. Results of the review are recorded and maintained. 

Occasional benchmark comparisons with other organizations can be useful. Reference 
processes, practices and other capabilities can be accessed through either direct 
contact or an intermediary’s compilations of benchmarked processes, practices and 
other capabilities. 

This section is not complete without a caution. Leaders in management research 
advise organizations also to reassess the utility of process management programs and 
apply them with discrimination. 12 “In the appropriate setting, process management 
activities can help companies improve efficiency, but the risk is that you misapply 
these programs, in particular in areas where people are supposed to be innovative. 
Brand new technologies to produce products that don’t exist are difficult to measure. 
This kind of innovation may be crowded out when you focus too much on processes 
you can measure.” 13 

8.7.2 Quality Assurance 

The primary objective of quality assurance (QA) is to produce an end result that meets 
or exceeds stakeholder expectations. Using a quality system program, manufacturers 
(for example) establish requirements for each type or family of product to achieve 
products that are safe and effective. To meet this objective they establish methods and 
procedures to design, produce, distribute, Service, and document devices that meet 
the quality system requirements. Quality management is the topic of chapter 6.6 and 
is closely related to the verification and validation processes. 

QA is generally associated with activities such as failure testing, statistical control, 
and total quality control. Many organizations use statistical process control as a 
means to achieve Six Sigma levels of quality. Traditional statistical process Controls 
use randomly sampling to testing a fraction of the output for variances within critical 
tolerances. When these are found, the manufacturing processes are corrected before 
more bad parts can be produced. 

Quality experts 14 , 15 have determined that if quality cannot be measured, it cannot 
be systematically improved. Assessment provides the feedback needed to monitor 
performance and make mid-course corrections. It provides data for diagnosing 
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difficulties and pinpointing improvement opportunities. A widely used paradigm for 
QA management is the Plan-Do-Check-Act approach, also known as the Shewhart 
cycle. 16 

Quality pioneer W. Edwards Deming stressed that meeting user needs represents 
the defining criterion for quality and that all members of an organization need to 
participate actively in “constant and continuous” quality improvement — to commit 
to the idea that “good enough isn’t.” 17 His advice marked a shift from inspecting for 
quality after production to building concern for quality into enterprise processes. 
As an example, in 1981, Ford launched a quality campaign - see Figure 8-5 - which 
went beyond getting good workers and supporting them with high-quality training, 
facilities, equipment, and raw materials. By characterizing quality as a “job,” 
everyone in the organization is motivated to concern themselves with quality and its 
improvement — for every product and customer. 18 

..... . 

Q^u A L I T Y IS JOB 1. 

Figure 8-5 Banner from Ford quality campaign 

Total Quality Control deals with understanding what the stakeholder/customer really 
wants. If the original needs statement does not reflect the relevant quality requirements, 
then quality can be neither inspected nor manufactured into the product. For instance, 
the 0resund Bridge consortium included not only the bridge material and dimensions 
but operating, environmental, safety, reliability and maintainability requirements. 

Product certification is the process of certifying that a certain product has passed 
performance or quality assurance tests or qualification requirements stipulated in 
regulations such as a building code or nationally accredited test standards, or that 
it complies with a set of regulations governing quality or minimum performance 
requirements. Today medical device manufacturers are advised to use good judgment 
when developing their quality system and apply those sections of the Food and Drug 
Administration Quality System Regulation that are applicable to their specific 
products and operations. The regulation, 21-CFR-820.5 is continuously updated since 
its release in 1996. It ought not to be possible to repeat the errors of the Therac-25 
project. 

8.8 Resource Management 

The purpose of Resource Management is to maintain and manage the people, 
hardware, and support tools required by the portfolio of enterprise projects. The 
Resource Management Process is the topic of chapter 6.5. 

Resource management is the efficient and effective deployment of an enterprise’s 
resources when and where they are needed. Such resources may include inventory, 
human skills, production resources, or information technology. An optimised goal 


Page 8.13 of 18 

Copyright ©2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. 


INCOSE-TP-2003-002-03 
June 2006 


INCOSE Systems Engineering Handbook v. 3 


is to achieve 100% utilization of every resource, but this is unlikely when providing 
some minimum level of Service while minimizing cost. Resource management relies 
heavily on forecasts into the future of the demand and supply of various resources. 

Project managers face their resource challenges competing for scarce talent in the 
larger enterprise pool. They must balance access to the experts they need for special 
studies with stability in the project team with its tacit knowledge and project memory. 
Today’s projects depend on teamwork and optimally multi-disciplinary teams. Such 
teams are able to resolve project issues quickly through direct communication between 
team members. Such intra-team communication shortens the decision-making cycle 
and is more likely to result in improved decisions because the multi-disciplinary 
perspectives are captured early in the process. However, studies have shown that 
group decisions are often “riskier” resulting in the potential for greater innovation. 

In a multi-disciplinary team, each member comes from a discipline with its own 
perspective. They are responsible for representing that viewpoint, while at the same 
time establishing the necessary relationships with the other members. However, team 
results are condemned to mediocrity unless each member confronts the team with 
challenging ideas while focusing on the final result. Using concurrent development, 
see Figure 8-6, it may be possible to finish the work faster and thus return valuable 
skills back to the personnel pool, having achieved a successful delivery. 


TRADITIONAL DEVELOPMENT 
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6 
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Figure 8-6 Shorter delivery time with concurrent development vs. traditional 

As early as 1974, Chase had identified the importance of Communications and that 
“system designs are dependent upon the effective integration of multidisciplinary 
efforts.” 19 He recommended that the organization of a system project should provide 
opportunity for all disciplinary specialists to work together continuously on a face-to- 
face basis and, most importantly, to acquire the Systems viewpoint and understanding 
of the role that their specific knowledge can provide in deriving a particular system 
design. 20 

Chase advocates identifying the lines of communication among tasks in terms of 
interdependencies and mutual constraints to reveal that different stages of the life 
cycle call for different tasks and different personnel skills. Properly used, this allows 
management to acquire and properly utilize the proper combination of specialist 
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and generalist skills. A project avoids “bureaucratization” of the design approach 
by streamlining the organization and integrating the various specialist backgrounds 
into common system-oriented task groups with loyalties directed toward the systems 
design effort. 

Modern projects use the concepts of integrated product and process teams to establish 
a project organization. 21 

8.9 Validation 

System validation confirms that the system, as built (or as it will be built), satisfies 
the stakeholders’ stated needs. Validation ensures the requirements and the system 
implementation provide the right solution to the customer’s problem. In other words, 
“you built the right thing.” Validation is the topic of chapter 4.9. 

Validation determines that a system does all the things it should and does not do what 
it should not do. End users and other stakeholders are usually involved in validation 
activities, but when warranted, an independent third party may be called in to perform 
validation. Validation may take place either in the operational environment or a 
simulated operational environment if conditions are hazardous. Both validation and 
verification activities often run concurrently and may use different portions of the same 
environment. 

Requirements validation is conducted as part of requirements elicitation to provide 
early assurance that the requirements are the “right” requirements for guiding the 
development process to a conclusion which satisfies the stakeholders. Requirements 
validation is often based on requirements analysis; exploration of requirements 
adequacy and completeness; assessment of prototypes, simulations, models, 
scenarios, and mock-ups; and by obtaining feedback from customers, users or other 
stakeholders. Much of the discussion regarding verification (below) also can be 
applied to validation. 

The objects of validation are the designs, prototypes, and final systems elements, as 
well as the documentation and training materials that describe the system and how to 
use it. Validation results are an important element of decision gate reviews. 

8.10 Verification 

System verification addresses whether the system, its elements, and its interfaces 
satisfy theirrequirements. Verification ensures the conformance to those requirements; 
in other words that “you built it right.” This is the topic of chapter 4.7. 

Verification encompasses the tasks, actions and activities performed to evaluate 
the progress and effectiveness of the evolving system Solutions (people, products 
and process) and to measure compliance with requirements. The primary function 
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of verification is to determine that system specifications, designs, processes and 
products are compliant with requirements. A continuous feedback of verification data 
helps to reduce risk and to surface problems early. The goal is to completely verify 
system capability to meet all requirements prior to production and operation stages. 
Problems uncovered at in these stages are very costly to correct, see Figure 2-3. Early 
discovery of deviations from requirements reduces overall project risk and helps the 
project deliver a successful, low cost system. 22 Verification results are an important 
element of decision gate reviews. 

Verification analysis can be initiated once a design concept has been established. If a 
requirements traceability matrix is used, each requirement has a verification activity 
associated with it. A unique requirements identifier can be used for traceability to 
the test plans, test procedures, and test reports to provide a closed loop verification 
process from demonstrated capability back to the requirement. Basic verification 
activities are: 

Inspection: an examination of the item against applicable documentation to 
confirm compliance with requirements. Inspection is used to verify properties best 
determined by examination and observation (e. g., - paint color, weight, etc.). 

Analysis: use of analytical data or simulations under defined conditions to show 
theoretical compliance. Used where testing to realistic conditions cannot be 
achieved or is not cost-effective. Analysis (including simulation) may be used 
when such means establish that the appropriate requirement, specification, or 
derived requirement is met by the proposed solution. 

Demonstration: a qualitative exhibition of functional perfonnance, usually 
accomplished with no or minimal instrumentation. Demonstration (a set of test 
activities with system stimuli selected by the system developer) may be used to 
show that system or subsystem response to stimuli is suitable, see Figure 8-7. 
Demonstration may be appropriate when requirements or specifications are given 
in statistical terms (e. g., mean time to repair, average power consumption, etc.). 

Test: an action by which the operability, supportability, or performance capability 
of an item is verified when subjected to controlled conditions that are real or 
simulated. These verifications often use special test equipment or instrumentation 
to obtain very accurate quantitative data for analysis. 

A fifth verification method, certification, refers to verification against legal or 
industrial standards by an outside authority without direction to that authority as 
to how the requirements are to be verified. For example, this method is used for 
electronic devices; CE certification in Europe, and UL certification in the US and 
Canada. 
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Figure 8-7 A test platform for analyzing battery performance at high loads 23 

The design of the verification activity involves choosing the most cost-effective mix 
of simulations and physical testing, and integrating test results to avoid unnecessary 
redundancy. Complete simulation of the system (both performance and design) has 
become common-place in major system development, and has resulted in reduced 
development time and cost. 

There are four basic test categories. They are: 

Development Test: Conducted on new items to demonstrate proof of concept or 
feasibility. 

Qualification Test: Tests are conducted to prove the design on the first article 
produced, has a predetermined margin above expected operating conditions, for 
instance by using elevated environmental conditions for hardware. 

Acceptance Test: Conducted prior to transition such that the customer can decide 
that the system is ready to change ownership status from supplier to acquirer. 

Operational Test: Conducted to verify that the item meets its specification 
requirements when subjected to the actual operational environment. 

Human engineering engineers develop task descriptions, operational sequence 
diagrams, and evaluate the human-machine interface to establish the required 
interactions with the hardware and Software. Verification analysis checks that tests 
have been established using realistic scenarios to demonstrate human reaction times 
that satisfy operational requirements. Maintainability demonstrations should include 
a sufficient number of tests and problem areas to provide a high confidence level of 
meeting maintainability parameters, such as Mean-Time-To-Repair. Production line 
tests are recommended for items that are new or have not been previously applied to 
this application. The tests demonstrate producibility and repeatability. 
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9 Specialty Engineering Activities 

The topics in this chapter are covered in alphabetical order by topic title to avoid giving 
more weight to one topic over another. See Table 1-1 for an overview. The objective 
of this chapter is to give enough information to Systems engineers to appreciate the 
significance of the engineering specialty area, even if they are not an expert in the 
subject. It is recommended that subject matter experts are consulted and assigned as 
appropriate to conduct specialty engineering analysis. More information about each 
specialty area can be found in references to external sources and the IPAL. 

With a few exceptions, the forms of analysis are similar to those associated with systems 
engineering. Most analysis methods are based on the construction and exploration 
of models that address specialized engineering areas, such as electro-magnetic 
compatibility, reliability, safety, and security. Not every kind of analysis and associated 
model will be applicable to every application domain. Figure 9-1 contains a generic 
Context Diagram for Specialty Engineering Activities. 



Figure 9-1 Generic Context Diagram for Specialty Engineering Activities 

9.1 Design forAcquisition Logistics - Integrated Logistics 
Support 

The Operation and Maintenance Processes are defined in chapters 4.10 and 4.11, 
respectively. The sustainment of these processes during the Utilization and Support 
Stages is dependent on actions set in motion during the earlier stages. These activities 
are known under various titles, such as Integrated Logistics Support (ILS), Supply Chain 
Management, Product Support, Customer Services, and similar names. The full scope 
of ILS includes Acquisition Logistics - activities influencing the design of a system 
and its readiness for utilization and support; and, Operational Logistics - activities 
that ensure that the right materiel and resources, in the right quantity and quality, are 
available at the right place at the right time throughout the Utilization and Support 
Stages. Operational logistics also receives attention under the heading of supply chain 
management. This handbook uses the term ILS, and this section focuses on Acquisition 
Logistics. Strategies and tactical plans for ILS are established as part of the Enterprise 


Page 9.1 of 16 

Copyright ©2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. 


INCOSE-TP-2003-002-03 
June 2006 


INCOSE Systems Engineering Handbook v. 3 


Processes, and will drive the basic considerations to be applied during the Acquisition 
Logistics activities. 

Many different analyses are used to consider whether it is more cost effective to 
influence the initial design of the system or to plan for spare parts and repairs during 
utilization. When initial acquisition costs are fixed, this can have a downstream 
impact on the funding that will be needed in future years. 

9.1.1 “-ilities” influencing the system design 

Acquisition Logistics focus on design requirements criteria, applicable to all system 
elements, and comprise (but is not limited to) the following list of engineering 
specializations: Affordability (Life Cycle Cost); Cost/System Effectiveness; 
Disposability (Recycling / Retirement); Maintainability; Packaging, Handling, Storage 
and Transportation (PHS&T); Producibility (Manufacturability); Reconfigurability 
(Flexibility / Standardization); Reliability; Security; Supportability (Serviceability); 
Survivability; and, Vulnerability - sometimes referred to as the “-ilities”. Figure 9-2 
illustrates the relationship between ILS analysis activities. 



• Training 

Figure 9-2 Acquisition Logistics Activities 

The Availability, Reliability and Maintainability of a system are major drivers in 
the use of support resources and the related in-service costs. The probability that 
the system, when used under stated conditions, will operate satisfactorily is often 
expressed as Availability, which in turn, is dependent on the design for Maintainability 
and Reliability as well as the support arrangements during the Utilization and 
Support Stages. Flowever, the term Availability in itself is imprecise as it may, or 
may not include logistics and administrative delay time, corrective and preventive 
maintenance. Therefore, we categorize Availability into: Inherent, Achieved, or 
Operational Availability. Reliability is concerned with the probability of the system- 
of-interest working when it should. Maintainability is concerned with keeping the 
system working and the ease of putting things right once they have gone wrong. 1 
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A summarizing denomination for Availability, Reliability, Maintainability and 
Supportability, may also be known as Dependability. The Dependability of a system 
describes its ability to fulfill the required performance under given conditions, taking 
degradation of performance due to failure and maintenance into consideration. Under 
certain conditions, it may be necessary to introduce redundancy into the design of 
a system to enhance the system’s reliability by providing two or more functional 
paths or physical objects in areas that are critical to successfully achieve specified 
Availability under given conditions. Likewise, it is important to eliminate single 
points of failure during the design of a system. 

In the discussion of the 0resund Bridge case, the survivability of the bridge in the 
event of ship collisions, and analysis of the design to ensure that traffic flow is not 
interrupted by accidents are two examples of ILS-related trade studies that were 
conducted. 

Another important factor to consider during the design of a system is the Packaging, 
Handling, Storage and Transportation (PHS&T), which includes all special provisions, 
materials and containers, and how the system or the parts thereof shall be handled, 
distributed and stored. In addition to the system itself, PHS&T also covers spares and 
consumables. 

Packaging can occasionally be more expensive than the product itself. Packaging 
requirements often have conflicting user objectives. A merchant wants the package 
to be so tough that a shoplifter cannot steal parts from inside the package while it is 
on the store shelf. The consumer wants the package to be easy to open when they get 
it home. Experience as a consumer suggests that the merchant won; many packages 
are almost impossible to open without using tools. 

Handling can be a source of failure. A warehouse worker can - and sometimes does 
- drive a folk-lift through a package. Airline baggage handlers are known to throw 
boxes onto carts, even though they are marked “fragile.” 

The storage environment can impose significant constraints on packaging and the 
system itself. Humidity, dust, and temperature are typical environmental concerns. In 
addition, warehousing places constraints on size and density of objects. 

Transportation is often overlooked when designing a system. Use of freight trains or 
cargo planes imposes limits on height, width, length and weight. For some Systems, 
these constraints may force building multiple system elements that are not assembled 
until delivered to the operational site. For example after completing a new post office 
building in a major USA city at a cost of $140 million, the city engineers found 
that post office trucks would not fit into the enclosed loading dock. Similarly, food 
trucks that normally Service Denver Airport’s restaurants are too high to fit under the 
elevated walkways that cross over their access roads. 
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Acquisition Logistics / ILS is important and relevant to Systems engineers. As 
consumers themselves, systems engineers have experienced the frustration of 
unreliable systems. Those who have maintained systems at some point in their careers 
know that failure to acknowledge that humans maintain systems can cause significant 
problems in an operational environment. When availability gets too bad, systems are 
sometimes simply shut down in frustration, which can cause significant rework at 
considerable cost. The huge variety of Acquisition Logistics analyses are best carried 
out by subject matter experts, because they are familiar with the mathematics that 
underlie the techniques, with the tools that are available to support these analyses, 
and with the factors that influence the outcome of these analyses. 

9.1.2 “-ilities” analysis methods 

Within the fields of Reliability, Maintainability and Supportability Engineering there 
are several analyses that are performed iteratively and recursively as they are co- 
dependent on results of other analyses. This section briefly addresses some of the 
most useful and common analyses techniques. 

Failure Modes Effects and Criticalitv Analysis (FMECA) should be performed 
early enough to influence equipment design. The aim is to minimize maintenance 
requirements and thereby cost. FMECA indicates that potential failures may occur that 
either: cannot be removed through re-design but can be avoided through preventive 
maintenance; or have a non-critical impact and therefore can be allowed to occur, 
with subsequent rectification through corrective maintenance. 

FMECA is a means of recording and determining what functions the equipment is 
required to perform, and 

• How these functions could fail 

• Possible causes of the failures 

• Effects the failures would have on the equipment or system 

• The criticality of the failures 

Level of Repair Analysis is the process of evaluating system elements to first 
determine (in most cases from an economic point of view, only) if the element or 
system should be discarded or repaired. If repairing the item is feasible, establish 
where the repair should take place; e.g. at home, locally, or at the factory. This is 
expressed as an organizational level. This analysis is conducted throughout the 
system life cycle. The handling of a system element may change based on experiences 
from prior decisions. 

Logistic Support Analysis ( LSA) / Supportability Analysis is a structured method of 
analyzing the support implications of system elements as they are being developed, 
with the aim of identifying features of the design that could result in excessive 
expense during the operational life of the system. Once identified, these items can be 
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the subject of trade-offs to revise the design in order to reduce later costs. Once the 
design is more fully defined, during the late activities of the Development stage, the 
LSA can identify all the logistic resources necessary to support the equipment and 
the impact on the existing support infrastructure. LSA is only cost effective where it 
is likely to generate benefit in terms of a more supportable design or better defined 
support requirements and hence reduced life cycle cost. 

Reliabilitv Centered Maintenance Analvsis (RCM) can be performed to assess the 
most cost efficient preventive maintenance program for the system. RCM is best 
initiated very early in the Development Stage and evolves throughout the Production 
Stage. As such it can also successfully be introduced for systems already in operation, 
as it can be accomplished using a decision tree, leading the analyst through a logical 
sequence of the nature and frequency of applicable preventive maintenance tasks. 

Survivability Analysis is performed when items must perform critical functions in 
a hostile operational environment. Threats to be considered include conventional, 
electronic, nuclear, biological, Chemical, and other weapons, and terrorism or 
sabotage, erratic human behavior, and harsh environmental conditions, such as ocean 
salinity. Critical survivability characteristics are identified assessed, and analyzed 
to evaluate their impact on system performance and effectiveness. 2 A system is said 
to be survivable if it can fulfill its purpose in a timely manner, even in the presence 
of attacks or failures. Because of the severe consequences of failure, enterprises 
increasingly focus on system survivability as a key risk topic. 

The Spitfire (see Figure 9-3) was designed with an elliptical wing, giving greater 
speed and maneuverability (perhaps the most critical -ility of all for a warplane). This 
was at a price: 13000 man-hours per airframe. Willy Messerschmitt had optimized 
for speed and manufacturability: only 4000 man-hours; but the Bf 109 was no faster 
than the Spitfire, and was consistently out-turned by it. The elliptical wing had been 
considered, but rejected it as too difficult to manufacture. 3 



System Securitv Analvsis identifies and evaluates system vulnerabilities to known or 
postulated security threats, and recommends means to eliminate the vulnerabilities 
or to at least reduce the susceptibility to compromise, damage, or destruction to an 
acceptable level of risk. 
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9.2 Electromagnetic Compatibility Analysis 

Electromagnetic compatibility (EMC) analysis is performed on electric or electronic 
items to ensure that they can perform in their intended electromagnetic environments. 
Analysis also ensures that items that are intentional radiators of radio frequency 
energy comply with commercial, governmental, and relevant international policies 
for radio frequency spectrum management and do not interfere with other signals 
- Electromagnetic interference (EMI). Even cable or speaker wire routing for 
home devices, such as a television, must consider EMI/EMC to achieve maximum 
performance and ensure safety of the users. 

9.3 Environmental Impact Analysis 

Europe, the USA and many other nations recognize regulations that control and restrict 
the environmental impact that a system may inflict on the biosphere. The ISO 14000 
series, Environmental Management 4 standards are an excellent resource for analysis 
and assessment methods for the protection of the environment. Failure to comply with 
environmental protection laws carries penalties and may result in the system not being 
approved for development. The issue is discussed in several references. 5,6 

The focus of environmental impact analysis is on potential deleterious effects of a 
proposed system’s development, construction, use, and disposal. Ali countries that 
have legally expressed their concern for the environment restrict the use of hazardous 
Chemicals and components (e.g. mercury, lead, cadmium, chromium 6, and radioactive 
materials) with a potential to cause human disease or to threaten endangered species 
through loss of habitat or impaired reproduction. Concern extends over the full life cycle 
of the system to be developed, as is made evident by the European Union’s resolution 
to adopt within 2006 a legal restriction that system developers and their component 
suppliers retain lifetime liability for decommissioning systems that they build and sell. 

The 0resund Bridge is an example of how early analysis of potential environmental 
impacts ensures that measures are taken in the design and construction to protect the 
environment with positive results. Two key elements of the success of this initiative 
were the continual monitoring of the environmental status and the integration of the 
environmental concern into the requirements from the Owner. 

Disposal analysis is a significant analysis area within Environmental Impact Analysis. 
Traditional landfills for non-hazardous solid wastes have become less available within 
the large city areas and the disposal often involves transporting the refuse to distant 
landfills at considerable expense. The use of incineration for disposal is often vigorously 
opposed by local communities and Citizen committees, and poses the problem of ash 
disposal; the ash from incinerators is sometimes classified as hazardous waste. Local 
communities and governments around the world have been formulating significant new 
policies to deal with the disposal of non-hazardous and hazardous wastes. 
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One goal of the architecture design is to maximize the economic value of the system- 
elements residue and minimize the generation of waste materials destined for disposal. 
Because of the potential liability that accompanies the disposal of hazardous and 
radioactive materials the use of these materials is carefully reviewed and alternatives 
used where and whenever possible. The basic tenet for dealing with hazardous waste 
is the “womb-to-tomb” control and responsibility for preventing unauthorized release 
of the material to the environment. This may include designing for reuse, recycling, 
or transformation (e. g. composing, bio-degradation). 

In accordance with United States and European Union laws, system developers and 
component manufacturers must analyze the potential impacts of the Systems that they 
construct, and must submit the results of that analysis to government authorities for 
review and approval to build the system. Failure to conduct and submit the environmental 
impact analysis can result in severe penalties for the system developer, and may result in 
an inability to build or to deploy the system. It is best when performing environmental 
impact analysis to employ subject matter experts who are experienced in conducting 
such assessments and submitting them for governmental review. 

9.4 Human Factors 

The Human Engineering or Human Systems Engineering effort affects every portion 
of the system that has a human-machine interface. It is essential to integrate human 
system factors into the design of items. The objective is to achieve a balance between 
system performance and cost by ensuring that the system design is compatible with 
the capabilities and limitations of the people who will operate, maintain, transport, 
supply, and control the system. It is essential from both ethical and liability perspectives 
that a concern for human operators, maintainers, and administrators is reflected in 
the design of Systems. In situations where it is not possible to eliminate all risks by 
design, remediation steps can be identified and taught to enable people to reduce the 
risk of temporary or permanent injuries. 

Human Performance and Human Engineering Design Requirements 

During requirements analysis, requirements from a variety of sources and disciplines 
are analyzed to resolve conflicts. The human factors engineer is primarily responsible for 
two types of requirements; human performance requirements and human engineering 
design requirements. Human performance requirements include times and accuracies 
for tasks assigned to humans. The human factors engineer ensures that the proposed 
requirements are in fact achievable by the intended operators and users. The human 
engineer may in some cases, define the human performance requirements based on 
external requirements, specifications of other system elements, or the capabilities and 
limitations of the prospective operators and users. 

Human performance requirements are frequently derived from or at least bounded by 
other performance requirements within the system. The accuracy, response time, and 
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other attributes of the operator tasks will affect similar attributes at the system level. 
The implementation of the requirements needs to be verified, and additional design 
decisions need to be made as the design progresses. 

The human engineering design requirements concern specific aspects of the hardware 
and Software that are necessary to fit the operators and assist them in their assigned tasks. 
These requirements define what must be designed and constructed to permit the operators 
and users to interact with one another and the rest of the system. Such requirements 
commonly address topics that make the work area more effective (use of colors, button 
and knob design and layout, etc.). It is generally good practice to minimize characteristics 
that require extensive cognitive, physical, or sensory skills; require the performance of 
unnecessarily complex tasks; require tasks that result in frequent or critical errors. 

Ergonomics is the name of the engineering discipline concerned with the elimination 
of aspects of a system design that could cause temporary or permanent injury to people 
who operate, maintain, or otherwise use the system. This may include identification 
of steps people can take to reduce the risk of injury when operating, maintaining, or 
otherwise using the system after it is deployed. It is also a matter of ethics that systems 
do not present undue risks to the people who will use them. The ergonomics engineering 
process begins during the Concept Stage of the system life cycle and continues 
throughout the life of the system. Figure 9-4 identifies a three-step process to reduce the 
risk that a system will require costly rework in order to be authorized to deploy, or fail to 
be allowed to deploy at all; (1) identify the key design considerations and address them 
in step 3, during development of the system, (2) build the right team, and (3) manage the 
human factors engineering process. 



Figure 9-4 Ergonomics Engineering Minimizes 
Risks to System Stakeholders 7 
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The Occupational Safety and Health Agency has a website 8 that features eight eTools 
that address ergonomics for a number of industries and occupations, including 
baggage handling, beverage delivery, Computer workstations, grocery warehousing, 
health care, poultry processing and sewing. 

The design shown in Figure 9-5 may meet simple requirements for a teapot, but no 
human would want to use it. The author discusses many examples of implemented 
Systems from calculator keypads with keys in a non-intuitive location to department 
store door handles where there is no indication where to push to open the door. The 
consistent issue in these instances is a lack of human factor considerations in the design. 
In many cases, styling and appearance are allowed to override good engineering, such 
as the car dash board design in which the identically shaped handles for brake release 
and hood release are placed side-by-side under the dash with no easily distinguished 
marking on either handle. Rental car drivers beware! 


rH ' DE/I6N °' 
EVERYDAY 
THING/ 



Figure 9-5 Unique Teapot Shown on Book Cover 9 


9.5 Mass Properties Engineering Analysis 

Mass Properties Engineering 10 (MPE) is done to assure that the system or system 
element has the appropriate mass properties to meet the requirements. The mass 
properties include weight, the location of center of gravity, inertia about the center of 
gravity, and product of the inertia about an axis. 

Typically, the initial sizing of the physical system is derived from other requirements, 
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such as minimum payload, maximum operating weight, or human factors restrictions. 
Mass properties estimates are done at all stages of the system life cycle, based on the 
information that is available at the time, which may range from parametric equations 
to a three-dimensional product model, to actual inventories of the product in Service. 
A risk assessment is done using techniques such as uncertainty analysis or Monte 
Carlo simulations to verify that the predicted mass properties of the system will meet 
the requirements, and that the system will operate with in its design limits. Validation 
is usually done at the end of the Production Stage to assure all parties that the delivered 
system meets the requirements, and then several times during the Utilization Stage to 
assure safety of the system, component or human operator. For a multi-billion dollar 
project such as oil platform or warship the MPE level of effort is significant. 

One trap in MPE is that design mangers may believe that their 3 -D modeling tools 
can be used to estimate the mass properties of the system or system element. This 
is problematic because: (1) not all parts are modeled on the same schedule, (2) most 
parts are modeled neat, that is without such items as manufacturing tolerances, paint, 
insulation, fittings etc. which can add from 10 to 100% to the system weight. For 
example, the liquid in piping and tanks can weigh more than the structural tank or 
metallic piping that contain it. 

MPE usually includes a reasonableness check of all estimates by using an alternative 
method. The simplest method is to justify the change between the current estimate 
and any prior estimates for the same system, or the same system element on another 
project. Another approach is to use a simpler estimating method to repeat the estimate 
then justify any difference. 

9.6 Modeling, Simulation, and Prototyping 

Modeling, simulation, and prototyping used during architecture design can 
significantly reduce the risk of failure in the finished system. These techniques enable 
the development of complex and costly enabling systems, such as a flight simulator 
or a high-volume production line, which allow validation of the system’s concepts, 
or supports training of personnel in ways that would otherwise be cost prohibitive. 
Systems engineers use modeling and simulation on large complex projects to manage 
the risk of failure to meet system mission and performance requirements. This form 
of analysis is best conducted by subject matter experts who develop and validate the 
models, conduct the simulations, and analyze the results. 

9.6.1 Modeling and Simulation 

Modeling and simulation are an effective and usually efficient way to address technical 
risk on a project, especially a large project, because they represent a cost-effective 
means to find and fix problems before development is concluded and production 
begins. Modeling helps generate data in the domain of the analyst or reviewer, not 
available from existing sources, in a manner that is affordable and timely to support 
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decision-making. The objective of modeling is to obtain information about the system 
before significant resources are committed to its design, development, construction, 
testing, or operation. Consequently, development, validation, and operation of the 
model must consume time and resources not exceeding the value of the information 
obtained through its use. 

A model is a mapping of the system-of-interest onto a simpler representation which 
approximates the behavior of the system-of-interest in selected areas. Models may 
be used to represent the system under development, the environment in which the 
system operates, or interactions with enabling systems and interfacing systems. 

Models can be used within most Systems Life Cycle Processes, such as the following. 

• Requirements Analysis: determine and assess impacts of candidate requirements 

• Architectural Design: evaluate candidate options 

• Verification: simulate the system’s environment and evaluate test data 

• Operations: simulate operations in advance of execution for planning and 
validation 

The result of modeling is to predict characteristics (performance, reliability, operations, 
and cost, etc.) across the spectrum of system attributes throughout its life cycle. The 
predictions are used to guide decisions about the system’s design, construction, and 
operation, or to verify its acceptability. Standard tools for all types of modeling are 
now available commercially for a wide range of system characteristics. 

9.6.2 Types of Models 

Models fail into one of two general categories - representations and simulations. 
Representations employ some logical or mathematical rule to convert a set of inputs 
to corresponding outputs with the same form of dependence as in the represented 
system, but do not mimic the structure of the system. Validity depends on showing, 
through analysis or empirical data, that the representation tracks the actual system in 
the region of concern. 

Simulations, on the other hand, mimic the detailed structure of the simulated system. 
They are composed of representations of system elements, connected in the same 
manner as in the actual system. The validity of a simulation depends on validity of 
the representations in it and the faithfulness of its architecture to the actual system. 
Usually the simulation is run through scenarios in the time domain to simulate the 
behavior of the real system. An example might be the simulation of a fluid control 
system made up of representations of the piping, pump, control valve, sensors, control 
Circuit, and the fluid running through the system. 

The type of model selected depends on the particular characteristics of the system 
which are of interest. Generally, it focuses on some subset of the total system 
characteristics such as timing, process behavior, or various performance measures. 
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Representations and simulations may be made up of one or several of the following 
types: Physical, Graphical, Mathematical (deterministic), and Statistical. 

Physical models exist as tangible, real-world objects which are identical or similar 
in the relevant attributes to the actual system. The physical properties of the model 
are used to represent the corresponding properties of the actual system. Examples of 
physical models include: wind tunnel, testbed, and breadboard/brassboard. 

Graphical models are a mapping of the relevant attributes of the actual system onto a 
graphical entity with analogous attributes. The geometric or topological properties of 
the graphical entity are used to represent geometric properties, logical relationships, or 
process features of the actual system. Examples of graphical models include: functional 
flow block diagrams, N 2 diagrams, logic trees, blueprints, schematics, and maps. 

Mathematical (deterministic) models use closed mathematical expressions or 
numerical methods to convert input data to outputs with the same functional 
dependence as the actual system. Mathematical equations in closed or open form 
are constructed to represent the system. The equations are solved using appropriate 
analytical or numerical methods to obtain a set of formulae or tabular data defining 
the predicted behavior of the system. Examples of mathematical models include: 
operational or production throughput analysis; thermal analysis; vibration analysis; 
load analysis; stress analysis; eigen value calculations; and linear programming. 

Statistical models are used to generate a probability distribution function for expected 
outcomes, given the input parameters and data. Statistical models are appropriate 
whenever truly random phenomena are involved as with reliability estimates, 
whenever there is uncertainty regarding the inputs such that the input is represented 
by a probability distribution, or whenever the collective effect of a large number 
of events may be approximated by a statistical distribution. Examples of statistical 
models include: Monte Carlo; logistical support; discrete and continuous models. 

A simulation can used to quickly examine a range of sizes and parameters, not just a 
“Point Design.” This will insure that the “best” solution is obtained - the system is the 
proper size throughout, with no choke points. Exercise the simulation using scenarios 
extracted from the concept of operations with inputs based on system requirements. 
Monte Carlo runs may be made to get averages and probability distributions. In addition 
to examining nominal conditions, non-nominal runs should also be made to establish 
system reactions or breakage when exposed to extraordinary (out-of-spec) conditions. 

9.6.3 Prototyping 

Prototyping is a technique that can significantly enhance the likelihood of providing 
a system that will meet the user’s need. In addition, a prototype can facilitate both 
the awareness and understanding of user needs and stakeholder requirements. This 
section will discuss briefly two types of prototyping; rapid and traditional. 
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Rapid prototyping is probably the easiest and one of the fastest ways to get user 
performance data and evaluate alternate concepts. A rapid prototype is a particular 
type of simulation quickly assembled from a menu of existing physical, graphical, or 
mathematical elements. Examples include tools such as laser lithography or Computer 
simulation shells. They are frequently used to investigate form and fit, human-system 
interface, operations, or producibility considerations. Rapid prototypes are widely 
used, and are very useful, but, except in rare cases they are not “prototypes.” 

Traditional prototyping is a tool that can reduce risk or uncertainty. A partial 
prototype is used to verify critical elements of the system-of-interest. A full prototype 
is a complete representation of the system. It must be complete and accurate in the 
aspects of concern. Objective and quantitative data on performance times and error 
rates can be obtained from these higher fidelity interactive prototypes. 

The original use of a prototype was as the first of a kind from which all others were 
replicated. However, prototypes are not “the first draft” of production entities. Prototypes 
are intended to enhance learning and should be set aside when this purpose is achieved. 
Once the prototype is functioning, changes will often be made to improve performance, 
or reduce production costs. Thus, the production entity may require different behavior. 
The Maglev train system may be considered a prototype (in this case, proof-of-concept) 
for longer distance Systems that will exhibit some but not all of the characteristics 
of the short line. Scientists and engineers are in a much better position to evaluate 
modifications that will be needed to create the next system. 

9.7 Safety & Health Hazard Analysis 

Safety and health hazards are hazards to the well-being of human operators, 
maintainers, administrators, or other users of a system. They are a major concern 11 
wherever hazardous materials are employed, such as the Chemical industries, 
building enterprises, medical and radiological equipment supply concerns, energy 
production, and aviation and space. A systems engineer in one of the cited industries 
or any number of other industries that deal with hazardous materials, processes or 
human activities must be aware that subject matter experts are available to perform 
the analyses that can identify these hazards and their attendant risks, and can help 
identify means to eliminate or at least mitigate the risks to acceptable levels. 

Safety risks are associated with such processes as complex machinery used in a 
manufacturing plant, or high-temperature metals in a Steel plant, or coal mining, or 
maintenance of deep sea platforms (among others); or with activities such as flying, or 
space travel or deep sea fishing (among others). While a safety decision tree can be a 
useful starting place to analyze processes and activities as well as physical components 
of systems, it is likely that the means to eliminate or reduce process and activity 
risks will be different. Construction of safety cages can protect people in a complex 
manufacturing work cell; “kill” buttons can be installed; and barriers can be constructed 
to make sure a person cannot fail (for example) into molten Steel; specialized training 
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and back-up safety equipment can available to (for example) divers that maintain 
off-shore oil rigs. The Therac-25 case illustrates the cost in human life that may 
result when adequate measures are not taken to build safety measures into potentially 
dangerous equipment. The specially designed Windows for the Maglev train dampen 
the noise level that would otherwise present a hazard to passengers. 

When the hazards are caused by materials used within the system, it is crucially 
important to isolate the materials by some safe means as they are used in the system, 
and to plan for their eventual substitution by non-hazardous materials as material 
Science advances. See Figure 9-6 for examples of protective clothing. 


Figure 9-6 Protective clothing for Hazmat Level A and bird flu 

Many governments have regulations that mandate that all hazards to human safety 
and health be reduced as far as is possible, and that all safety and health hazards that 
can not be eliminated are mitigated by other than system means to reach acceptable 
levels of risk. This means avoiding wherever possible the use ofhazardous materials, 
containing hazardous material that cannot be eliminated, and addressing the hazards 
associated with process and human activities that are required to support and maintain 
the system in its operational environment. It also means planning for the safe handling 
and disposal of hazardous materials, and including such effort in the life cycle cost 
models and cost forecasts for the system being developed. 

9.8 Sustainment Engineering Analysis 

Sustainment engineering helps ensure that a system continues to satisfy its objective 
over its intended lifetime. In that timeframe, system expectations will expand, the 
environments in which the system is operated will change, technology will evolve, 
and elements of the system may become unsupportable and need to be replaced. The 
desktop computing environment is a case in point. Today it is nearly impossible to 
find cables to support parallel port printers since the introduction of the Universal 
Serial Bus (USB). 
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Sustainment Engineering is an integrated effort designed to address industry 
needs regarding aging systems, and a need to maintain those Systems in operation. 
A sustainment program may include re-engineering electronic and mechanical 
components to cope with parts obsolescence, the development of automated test 
equipment, and extending the life of aging systems through technology insertion 
enhancements, and proactive maintenance. These changes will have significant 
impact on ILS analyses. 

9.9 Training Needs Analysis 

Training needs analyses support the development of products and processes for 
training users and maintainers of a system. Training analysis includes the development 
of personnel capabilities and proficiencies to accomplish tasks at any point in the 
system life cycle to the level they are tasked. These analyses address initial and 
follow-on training necessary to execute required tasks associated with system use and 
maintenance. An effective training analysis begins with a thorough understanding of 
the concept documents and the requirements for the system-of-interest. A specific list 
of functions or tasks can be identified from these sources, and can be represented as 
learning objectives for operators, maintainers, administrators and other users of the 
system. The learning objectives then determine the design and development of the 
training modules and their means of delivery. 

lmportant considerations in the design of training include who, what, under what 
conditions and how well each user must be trained and what training will meet the 
objectives. Each of the required skills identified must be transformed into a positive 
learning experience and mapped onto an appropriate delivery mechanism. The formal 
classroom environment is rapidly being replaced with or augmented by simulators, 
computer-based-training, internet-based distance delivery, and in-systems electronic 
support, to name a few. Updates to training content use feedback from trainees after 
they have some experience to improve training effectiveness. 


1 Blanchard, Ben and Wolter Fabrycky, Systems Engineering and Analysis, 3rd ed., Prentice Hall, 
1998. Ch. 12-13 include complete discussions of the metrics and calculations for Availability, 
Reliability and Maintainability. 

2 For discussion of Survivable Systems Analysis Methods see http://www.cert.org/archive/html/ 
analysis-method.html 

3 Alexander, Ian, Systems Engineering: -ilities for Victory, Downloaded from http://easyweb.easynet. 
co.uk/iany/consultancy/systems^engineering/ilities^for^victory.htm 

4 The ISO 14000 family of International Standards, www.iso.ch/iso/en/prods-services/otherpubs/ 
isol4000/index.html 

5 Botkin, Daniel B. and Edward A. Keller, Environmental Science: Earth as a Living Planet, 2nd 
edition, New York: John Wiley Sons, 1998. 
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6 Mary Edwards, an Assistant Professor at the University of Wisconsin, Madison, developed a guide 
that includes a chapter on environmental impact analysis. It can be found at http://www.lic.wisc. 
edu/shapingdane/facilitation/all*resources/impacts/analysis*environmental.htm 

7 Copyright© 2004 by Marsh Inc., www.marshriskconsulting.com/st/PDEv*C*371 , SC*228135*NR*30 
6-PI-233074.htm. 

8 The OSHA web site can be found at www.osha.gov/SLTC/ergonomics/ 

9 Norman, Donald A., The Design of Everyday Things, Doubleday, New York, NY 1988 

10 See Recommended Practices from the Society of Allied Weight Engineers at www.sawe.org. 

11 US Department of Labor, Job Hazard Analysis, Washington, DC: OSHA 3071, 2002 (available On- 
line at http://www.osha.gov/Publications/osha3071.pdf). 
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lOTailoring OverView 

10.1 Introduction 

Standards and handbooks are written to address generic practices that may, or may 
not, apply to a given organization or system-of-interest. Most are accompanied by a 
recommendation to adapt the processes and activities to the situation at hand. This 
adaptation is called tailoring. 

Throughout this handbook, advice has appeared about the formal use of these 
processes. Formality is highly dependent on the sophistication of the system, the 
organizations and the work to be accomplished. 

Tailoring scales the rigorous application of these processes to an appropriate level 
based on need and the system life cycle stage. For example, tighter assessment and 
control cycles are typical of earlier stages of the system life cycle. 

The principle behind tailoring is to establish an acceptable amount of process overhead 
committed to activities not otherwise directly related to the creation of the system. 
Oppressive overhead, with no visible value-added contributions, is demoralizing, and 
may result in a system that costs more than it is worth. Insufficient process results in 
uncoordinated human effort and thrashing 1 - which also adds cost. 

This chapter describes the process of tailoring this handbook to meet your needs. 

10.2 Tailoring Process 

Figure 10-1 is a notional graph for balancing formal process against the risk of cost 
and schedule overruns. As discussed in Chapter 2, insufficient systems engineering 
effort is generally accompanied by high risk. McConnell 1 describes the improvements 
in efficiency realized by adding process. But as the graph illustrates, too much formal 
process also introduces high risk. 
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Degree of formal Systems engineering process used on the project 



Figure 10-1 Tailoring requires balance between risk and process 2 

If too many or unnecessary processes are performed, increased cost and schedule 
impacts will occur with little or no added value to the integrity of the system. Tailoring 
processes is dynamic over the system life cycle depending on risk and the situational 
environment and should be continually monitored and adjusted as needed. Figure 10-2 
is the Context Diagram for the Tailoring Process described in this chapter. 



Figure 10-2 Tailoring Process Context Diagram 

10.2.1 Inputs to the Tailoring Process 

Tailoring is driven by the environment of the system life cycle stages. These 
environments determine the criteria for process tailoring: 
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Enterprise environment 

As indicated in chapter 6, the enterprise environment provides the context for most 
processes. Enterprise processes establish standards, policies, processes, goals, and 
objectives that are based on market environment and opportunities, governmental 
and other external laws and regulations, and enterprise strategies in response to these 
factors. The enterprise context includes the industry domain. 

Organization environment 

The work of an enterprise is conducted through organizations that execute strategy 
through programs and projects. Factors that influence tailoring at the organizational 
level include: 

• Stakeholders and customers - number of stakeholders, quality of working 
relationships 

• Project budget, schedule, and requirements 

• Risk tolerance 

• Complexity and precedence of the system 

Supplier environment 

Today’s Systems are more often an integration of many systems and system elements 
to create an operational environment. This demands that cooperation transcends the 
boundaries of any one organization or enterprise. Harmony between multiple suppliers 
is often best maintained by agreeing to follow a set of consistent processes and standards. 
In such environments, consensus on a set of practices is helpful but adds complexity to 
the tailoring process. 

10.2.2 Tailoring Process Activities 

Tailoring process activities should be conducted at least once for each stage of the 
system life cycle. 

Identify tailoring criteria for each stage - This activity establishes the criteria for 
including or excluding any process in the formal conduct of a given stage. Some 
essential processes, such as configuration management, build cumulatively throughout 
the system life cycle and may determine a set of permanent activities. Other processes, 
such as project planning, have a more limited range of applicability. 

Determine process relevance to cost, schedule, and risks - This activity analyzes 
the various environments, including their decision processes, relationships, and 
sensitivity to risks. The results define the appropriate tailoring of the review, decision 
and coordination methods for each process activity in each stage. 

Determine process relevance to system integrity - This activity analyzes the system 
features, intended environment, criticality of product/system use, reliability, and 
availability. It defines the appropriate tailoring of the process activities such as verification, 
qualification, level of analysis needed, and review and decision gate criteria. 
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Determine quality of documentation needed - This activity analyzes the support 
environment, system evolution, criticality of system functions, and internal and 
external interfaces. It defines the extent of detail needed in documentation for the 
project. 

Determine the extent of review, coordination and decision methods - This activity 
analyzes the project issues such as stakeholder diversity, extent of their involvement, 
nature of working relationships, (e. g. single, unified, or conflicting customer needs). 
These factors influence tailoring of formal reviews, coordination and decision 
methods, and Communications to fit the situation. 

10.2.3 Control of the Tailoring Process 

Elaboration of the control activities shown in Figure 10-2 are expanded upon in the 
following paragraphs. 

• Agreements - Agreements between enterprises create constraints on tailoring. 

• Stakeholder /Customer policy/legal - Issues of compliance to stakeholder, 
customer, and Enterprise policies, objectives, and legal requirements will 
sometime control the extent of tailoring. Certain documents and procedures 
may be mandatory in some situations. 

• Enterprise issues - The Enterprise environment Controls the processes used in 
the development, determines who needs to approve certain products, defines 
what form and content the product takes, and what information can (or cannot) 
be shared between entities, both internal and external. 

• Contracting Requirements - Methods of procurement or intellectual property 
will influence the extent of tailoring of the agreement process activities. 
Tolerance for formal processes is influenced by the contracting method - fixed 
price, cost plus fixed fee, time and material. 

• Life cycle process/model used- The Life Cycle process/model used determines 
the extent and nature of System Engineering process application, such as the 
number of reviews, development iterations, or decision points. 

Enterprise Risk Strategy 

Each participating enterprise will bring their tolerance for risk to the tailoring process. 
Risk adverse enterprises may need more detailed information than what the system 
requires, in order to build confidence in the processes. In such instances, tailoring 
may introduce extra activities that are removed as the level of trust builds between 
parties. 
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10.2.4 Enablers of the Tailoring Process 

The following paragraphs elaborate on the enablers shown in Figure 10-2. 

• Organizational learning - A key enabler in the tailoring process is experience 
with similar systems or familiarity between the participating parties. Beginning 
with less formal process structure for well-understood systems and established 
teams may yield significant cost savings without jeopardizing performance or 
quality. 

• Organizational maturity - Established and well documented processes that are 
used frequently among parties can contribute to successful outcomes. In such 
instances, it may be more disruptive and add cost to remove such a process. 
Consideration of the maturity of the participating parties, both individually and 
as a whole is an important enabler for tailoring. 

10.2.5 Outputs from the Tailoring Process 

The following paragraphs elaborate on the output shown in Figure 10-2. 

• Baseline of tailored processes - At the end of the tailoring process a set of 
formal processes and activities are identified. This plan includes, but is not 
limited to, a documented set of tailored processes, identification of the system 
documentation required, the identified reviews, decision methods and criteria, 
and the analysis approach to be used. 

• Tailoring sensitivity - The tailoring plan, processes, documentation and 
analyses are sensitive to change and increased knowledge from experience. 
By identifying the assumptions and criteria for tailoring, the tailoring process 
can be conducted throughout the life cycle to optimize the use of formal 
processes. 

10.3 Traps i n Tailoring 

The following discussion reveals traps in the tailoring process. 

1) Reuse of a tailored baseline from another system without repeating the 
tailoring process 

It is fallacious to assume that previously tailored baselines are appropriate for all 
systems. Prior successes are not a guarantee of future success. There is something 
unique in each system. 

2) Using all processes and activities, “just to be safe” 

The trap is that the each process carries an overhead cost. If this approach is 
taken, the quality of the system may actually degrade because of application 
of an inappropriate process. It can not be called tailoring if there is not a clear 
justification for the inclusion of every process in the plan. 
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3) Using a pre-established tailored baseline 

Enterprise shortcuts to create templates of baselines that can be taken off the shelf 
and applied to work based on arbitrary categorizations such as high, medium, 
and low risk systems can be counter-productive. They carry the same hazards as 
traps #1 and #2 above. Tailoring is important because the emphasis is placed on 
the system and only processes that support attainment of the objective in terms 
of quality and performance should be retained. 

4) Failure to include relevant stakeholders 

The tailoring process itself can become a unifying activity that establishes shard 
visions and understanding of the objectives. Suppliers, or other organizations, 
that are identified and not included in the process may feel disenfranchised with 
the result that they feel a lower level of commitment to the process baseline. 
When new parties are added, they should be familiarized with the baseline and 
asked to make constructive contributions. 


1 McConnell, Steven (1998). “The Power of Process,” IEEE Computer, www.stevemcconnell.com/ 
articles/art09.htm 

2 Adapted from a presentation given by Ken Salter, at the Jet Propulsion Laboratory in Pasadena CA. 
(2003) 
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Appendix A 

System Life Cycle Process N-squared chart 
per ISO/IEC 15288 


n-squared chart illustrating input-output dependencies between the System Life Cycle Processes 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

m 

fN 












X 

X 

X 

X 

X 






22 













X 

X 

X 

X 

X 





fN 

X 













X 

X 

X 

X 

X 



X 

20 


X 













X 

X 

X 

X 

X 



os 

X 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

00 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

r- 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

o 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

X 

X 

X 














Tf 





X 

X 

X 

X 

X 













m 






X 

X 

X 

X 

X 












fN 







X 

X 

X 

X 

X 

X 







X 

X 

X 











X 

X 


X 







X 

X 

o 











X 

X 


X 





X 

X 

X 

OS 












X 

X 


X 

X 

X 

X 

X 

X 

X 

00 




X 









X 

X 







X 

r- 





X 









X 

X 


X 


X 


X 

O 






X 









X 

X 




X 

X 

«rj 







X 









X 

X 


X 


X 

TT 

















X 

X 


X 

X 

m 









X 









X 

X 


X 

fN 










X 









X 

X 


- 











X 







X 

X 

X 

X 



Page Appendx-1 of 14 

Copyright ©2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. 


INCOSE-TP-2003-002-03 
June 2006 


INCOSE Systems Engineering Handbook v. 3 


Cross reference between the numbers on the diagonal to the process name 

1. stakeholder requirements definition 

2. requirements analysis 

3. architectural design 

4. implementation 

5. integration 

6. verification 

7. transition 

8. validation 

9. operation 

10. maintenance 

11. disposal 

12. project planning 

13. project assessment 

14. project control 

15. decision-making 

16. risk management 

17. configuration management 

18. information management 

19. enterprise management 
20.investment management 

21. system life cycle processes management 

22. resource management 

23. quality management 

How to read this N-squared chart: 

The outputs from lower-numbered processes that are input to higher-numberedprocesses 
are indicated by an x in the top diagonal. For an example, the shaded x at the intersection 
(1,8) reflects the passing of the validation criteria for stakeholder requirements into the 
Validation Process. 

The outputs from higher-numbered processes that are input to lower-numbered 
processes are indicated by an x in the lower diagonal. For example, the shaded x at the 
intersection of (21, 3) reflects that the Project processes and procedures identified by the 
SLC Processes Management Process influences the Architectural Design Process. 


Absence of an x in an intersection does not preclude tailoring to create a 
relationship between any two processes. 
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A1AA 

AP 

cm 

CM 

CMP 

COTS 

CSEP 

DOD 

DODAF 

DoE 

DOE 

ECP 

EMC 

EMI 

EN 

FMECA 

h 

IEC 

IEEE 

IID 

ILS 

IM 

IMP 

INCOSE 

IPAL 

ISO 

IT 

IV&V 

km 

LCC 

LSA 

m 

MIT 

MN 


Appendix B: Acronym List 

American Institute of Aeronautics and Astronautics [USA] 

Application Protocol 

centimeter 

Configuration Management 
Configuration Management Plan 
Commercial Off-The-Shelf 
Certified Systems Engineering Professional 
Department of Defense 

Department of Defense Architecture Framework [USA] 

Department of Energy 

Design of Experiments 

Engineering Change Proposal 

Electromagnetic Compatibility 

Electromagnetic Interference 

Engineering Notice 

Failure Modes, Effects and Criticality Analysis 
hour 

International Engineering Consortium 

Institute of Electrical and Electronics Engineers 

Incremental & Iterative Development 

Integrated Logistics Support 

Information Management 

Information Management Plan 

International Council On System Engineering 

INCOSE Process Asset Library 

International Organization for Standardization 

Information Technology 

Integration, Verification and Validation 

kilometer 

Life Cycle Cost 

Logistic Support Analysis 

meter 

Massachusetts Institute of Technology 
Mega Newton 
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MODAF Ministry of Defence Architecture Framework [UK] 

MOE Measure of Effectiveness 

MOP Measures of Performance 

MPE Mass Properties Engineering 

NASA National Aeronautics & Space Administration [USA] 

OMG Object Management Group 

OSI Open Systems Interconnection (for communication protocols) 

PFIS&T Packaging, Handling, Storage & Transportation 

PLCS Product Life Cycle Support 

QA Quality Assurance 

QMP Quality Management Plan 

R&D Research and Development 

R&M Reliability and Maintainability 

RCM Reliability Centered Maintenance 

RMP Risk Management Plan 

ROI Return on Investment 

RVTM Requirements Verification Traceability Matrix 

SE Systems Engineering; Systems Engineer 

SEMP System Engineering Management Plan, see SEP 
SEMS System Engineering Master Schedule 

SEP Systems Engineering Plan 

SLC System Life Cycle 

STEP STandard for the Exchange of Product model data 

SWOT Strength-Weakness-Opportunity-Threat 

SysML Systems Modeling Language 

TP Technical Product 

TPM Technical Performance Measure 

TQM Total Quality Management 

UML Unified Modeling Language 

URL Uniform Recourse Locator 

USA United States of America 

USB Universal Serial Bus 

V&V Verification and Validation 

WBS Work Breakdown Structure 
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Appendix C: Terms and definitions 

The term and definitions in italic font stvle are from ISO/IEC 15288: 2002(E) - 
Systems engineering - System life cvcle processes. 

Words not included in this glossary carry meanings consistent with dictionary 
definitions. 


acquirer 

the stakehoider that acquires or procures a product or 
Service from a supplier 

activity 

a set of actions that consume time and resources and whose 
performance is necessary to achieve, or contribute to, the 
realization of one or more outcomes 

Acquisition Logistics 

Technical and management activities conducted to ensure 
supportability implications are considered early and 
throughout the acquisition process to minimize support costs 
and to provide the user with the resources to sustain the 
System in the field. 

Agile 

Project execution methods can be described on a continuum 
from “adaptive” to “predictive.” Agile methods exist on 
the “adaptive” side of this continuum, which is not the 
same as saying that agile methods are “unplanned” or 
“undisciplined.” 

agreement 

the mntual acknowledgement of terms and conditions under 
which a working relationship is conducted 

baseline 

a specification or product that has been formally reviewed 
and agreed upon, that thereafter serves as the basis for 
further development, and that can be changed only through 
formal change control procedures 

Capability 

An expression of a system, product, function or process’ 
ability to achieve a specific objective under stated conditions. 

Commercial Off-The- 
Shelf(COTS) 

Commercial items that require no unique acquirer 
modifications or maintenance over the life cycle of the 
product to meet the needs of the procuring agency 

Configuration 

A characteristic of a system element, or project artifact, 
describing their maturity or perfomance. 

Context diagram 

This version of the handbook provides a high level view of 
the process-of-interest. The diagram summarizes the process 
activities, and their inputs and outputs from/to external 
actors; some inputs are categorized as Controls and enablers. 
A control governs the accomplishments of the process; an 
enabler is the means by which the process is performed. 
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Decision gate 

A decision gate is an approval event (often associated with 
a review meeting). Entry and exit criteria established for 
each decision gate; continuation beyond the decision gate is 
contingent on the agreement of decision-makers. 

Derived Rcquirements 

Detailed characteristics of the system-of interest that 
typically are identified during elicitation of stakeholder 
requirements, requirements analysis, trade studies or 
validation 

Design Constraints 

The boundary conditions, externally or internally imposed, 
for the system-of-interest within which the organization must 
remain when executing the processes during the concept and 
development stage 

enabling system 

a system that complements a svstem-of-interest during its life 
cycle stages but does not necessarily contribute directly to 
its function during operation 

Environment 

The surroundings (natural or man-made) in which the 
system-of-interest is utilized and supported; or in which the 
system is being developed, produced or retired. 

facilitv 

the physical means or equipment for facilitating the 
performance of an action, e.g. buildings, instruments, tools 

Failure 

The event in which any part of an item does not perform as 
required by its specification. The failure may occur at a value 
in excess of the minimum required in the specification, i.e., 
past design limits or beyond the margin of safety. 

enterprise 

that part of an organization with responsibility to acquire 
and to supply products and/or Services according to 
agreements 

Human Factors 

The systematic application of relevant information about 
human abilities, characteristics, behavior, motivation, and 
performance. It includes principles and applications in 
the areas of human related engineering, anthropometrics, 
ergonomics, job performance skills and aids, and human 
performance evaluation. 

“-ilities” 

The operational and support requirements a program must 
address (e.g., availability, maintainability, vulnerability, 
reliability, supportability, etc.). 

Life Cycle Cost (LCC) 

The total cost to the organization of acquisition and 
ownership of a system over its entire life. It includes all 
costs associated with the system and its use in the concept, 
development, production, utilization, support and retirement 
stages. 


Page Appendx-6 of 14 

Copyright ©2006 International Council on Systems Engineering, subject to restrictions listed on the inside cover. 


INCOSE-TP-2003-002-03 
June 2006 


INCOSE Systems Engineering Handbook v. 3 


life cycle model 

a framework of processes and activities concerned with 
the life cycle, which also acts as a common reference for 
communication and understanding 

Measure of Effectiveness 

A metric used to quantify the performance of a system, 
product or process in terms that describe a measure to what 
degree the real objective is achieved. 

N-squared diagrams 

This graphical representation can be used to define the 
internal operational relationships or external interfaces of the 
system-of-interest. 

operator 

an individual who, or an organization that, contributes to the 
functionality of a system and draws on knowledge, skills and 
procedures to contribute the function 

organization 

a group of people and facilities with an arrangement 
of responsibilities, authorities and relationships [ ISO 
9000:2000] 

Performance 

A quantitative measure characterizing a physical or 
functional attribute relating to the execution of a process, 
function, activity or task; Performance attributes include 
quantity (how many or how much), quality (how well), 
timeliness (how responsive, how frequent), and readiness 
(when, under which circumstances). 

process 

set of interrelated or interacting activities which transforms 
inputs into outputs [ISO 9000:2000] 

project 

an endeavor with defined start andfinish dates undertaken 
to create a product or Service in accordance with specified 
resources and requirements 

Proof-of-concept 

A nai've realization of an idea or technology to demonstrate 
its feasibility 

Requirement 

A statement that identifies a system, product or process’ 
characteristic or constraint, which is unambiguous, can 
be verified, and is deemed necessary for stakeholder 
acceptability. 

resource 

an asset that is utilized or consumed during the execution of 
a process 

Specialty engineering 

Analysis of specific features of a system that requires special 
skills to identify requirements and assess their impact on the 
system life cycle 

stage 

a period within the life cycle of a system that relates to the 
State of the system description or the system itself 
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stakeholder 

a party having a right, share or claim in a system or in its 
possession of characteristics that meet that party ’s needs 
and expectations 

supplier 

an organization or ari individual that enters into an agreement 
with the acquirerfor the supply of a product or Service 

system 

a combination of interacting elements organized to achieve 
one or more stated purposes 

Systems Engineering 

Systems Engineering is an interdisciplinary approach and 
means to enable the realization of successful systems. 

It focuses on defining customer needs and required 
functionality early in the development cycle, documenting 
requirements, and then proceeding with design synthesis and 
system validation while considering the complete problem. 
Systems Engineering considers both the business and the 
technical needs of all customers with the goal of providing a 
quality product that meets the user needs. [INCOSE] 

Systems Engineering 
Effort 

Systems Engineering effort integrates multiple disciplines 
and specialty groups into a set of activities that proceed from 
concept to production to operation. Systems Engineering 
considers both the business and the technical needs of all 
stakeholders with the goal of providing a quality system that 
meets their needs. 

Systems Engineering 
Plan 

Structured information describing how the system 
engineering effort, in form of tailored processes and 
activities, for one or more life cycle stages, will be managed 
and conducted in the organization for the actual project. 

system element 

a member of a set of elements that constitutes a 
system 

system-of-interest 

the system whose life cycle is under consideration 

system life cycle 

the evolution with time of a system-of-interest 
from conception through to retirement 

System of systems 

System of systems applies to a system-of-interest whose 
system elements are themselves systems; typically these 
entail large scale inter-disciplinary problems with multiple, 
heterogeneous, distributed systems. 
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Tailoring 

The marmer in which any selected issue is addressed in a 
particular project. The organization may seek to minimize 
the time and efforts it takes to satisfy an identified need 
consistent with common sense, sound business management 
practice, applicable laws and regulations, and the time 
sensitive nature of the requirement itself. Tailoring may be 
applied to various aspects of the project, including project 
documentation, processes and activities performed in each 
life cycle stage, the time and scope of reviews, analysis, and 
decision-making consistent with all applicable statutory 
requirements. 

trade-off 

decision-making actions that select from various 
requirements and alternative Solutions on the basis of net 
benefit to the stakeholders 

user 

individual who or group that benefits from a system during 
its utilization 

validation 

confirmation, through the provision of objective evidence, 
that the requirements for a specific intended use or 
application have been fulfilled [ISO 9000: 2000] 

verification 

confirmation, through the provision of objective evidence, 
that specified requirements have been fulfilled [ISO 9000: 
2000] 
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Appendix D: Comment Form 


Reviewed document: 

Name of submitter (first name & last name): 
Date Submitted: 

Contact info (email address): 

Type of submission (individual/group): 

Group name and number of contributors 

(if applicable) 


Insert Document Title 
John Doe III 
21-Aug-2010 

john.doe@anywhere.com 

group 

INCOSE XYZ WG 


(See SAMPLE FORM on following two pages 


Submit comments to TBD Working Group chair. Current WG chair will be listed at: 
http://www.incose.org/techcomm.html 

If this fails, comments may be sent to: 

info@incose.org (the INCOSE main Office), which can relay to the appropriate WG, if 
so reguested in the comment cover page. 
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